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Preface 


Obj ectives 

In Phase I of this project, we developed a theoretical method 
for constructing interfaces of database management systems 
(DBMSs) to host distributed heterogeneous database management 
systems. In Phase II, we sought to incorporate the strategies 
and techniques learned in Phase I to streamline the process of 
creating interfaces. Our ultimate goal is the creation if the 
Database Interface Design System (DIDS) to totally automate 
the interface creation process. We envision this system as an 
important software product for the 1990 s. 

While full implementation of DIDS was beyond the scope of this 
project, we had the certain technical objectives as part of 
the Phase II effort. The major objects are outlined as fol- 
lows: 

Interface Guidelines 

Our initial goal was to examine a large number of commer- 
cially available database management systems and to develop 
a hand book for builders of interfaces. These guidelines 
are a step by step approach to constructing interfaces. A 
subsequent goal is to construct a totally automated system 
of building interfaces using the guidelines. 

Inner vs. Outer Interfaces 

In the course of examining various commercial DBMS we deter- 
mined there were two distinct approaches to building inter- 
f aces » viz, inner interfaces in which the interface software 
is embedded directly into the code of the heterogeneous 
distributed host system, and outer interfaces in which the 
interface software is external to the host and a series of 
templates are used to execute the database commands. 

Refinement of Interface Templates 

The original templates were designed in Phase I of this 
project. The symbols in these templates, which represent 
DBMS-specific items for each resident interface were simple 
names to be replaced by strings in the actual interface. 

Our objective in Phase II was to refine these templates as a 
result of testing, and expand the template syntax to encom- 
pass more complex data structures and integrate these tem- 
plates into our overall system. 
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Front-end Processor Software 

An essential part of our automated system to build inter- 
faces is a user session to capture the DBMS-specif ic items 
to be used in the template. The solicited items are rarely 
just a single word, and can be quite complex in structure. 

In particular, for each item solicited in the user session, 
not only its value but its meaning or semantic use must be 
captured. A major objective was to develop software to 
capture the information and store it for use by the inter- 
face driver software. Our original idea was to code this 
software in a language such as C, but further research 
revealed that an expert system was more efficient. This 
front-end processor became known as the Template Generator 
Software as we developed it. 

Interface Driver Software 

The interface driver software is the engine of the entire 
project. The objective in building this program is to 
develop a process to extract the information captured by the 
user session and build database management system dependent 
templates from the skeleton templates and the information 
captured by the front end processor. 

Building of Interfaces as Test Cases 

The final objective was to apply our methodology and 
actually build some database interfaces to the DAVID system. 
The actual interfaces constitute the required deliverables 
for this project. 

Scope of work 

Personnel, Materials & Facilities 

Ken Wanderman & Associates, Inc. has provided the personnel, 
materials, and facilities necessary to develop a generalized 
strategy for building resident database interfaces as stated 
in our proposal number 86-I-II 07.09-6211. In particular, 
we have purchased a SUN 4, Sparcstation I computer to do all 
the development work on. The only work not performed on our 
premises is that work as done by subcontractors as specified 
in article C-2 of the contract. 
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Deliverables 

We have delivered considerably more than the contract speci- 
fies. In particular, the contract calls for the construc- 
tion of interfaces to: 

UNIFY 
ORACLE 
INGRES 
R BASE 

We have included these interfaces on the main deliverable 
tape except for R BASE which runs only on micro computers 
and thus awaits the transport of DAVID to personal comput- 
ers. The R BASE interface is included on a separate dis- 
kette . 

During the course of the project, we have come to believe 
that other interfaces would be of considerable more value to 
NASA. Therefore we have included interfaces for the follow- 
ing. 

FILE 

FITS 

FOCUS 

IDMS 

In particular the general FILE interface and the FITS inter- 
face will allow NASA scientists to immediately do important 
work. 

In addition we are delivering the source and executable code 
for the Template Generator Software portion of DIDS. These 
programs run on PC compatibles and are found on 3.5 inch 
diskettes. 

Conclusions 

We have developed an interface method, which for large classes 
of commercial resident DBMS's's, will yield usable interfaces 
to the DAVID system and by extension to any heterogeneous dis- 
tributed DBMS. In addition these interfaces can be built 
within a few minutes or hours at the most. See the User Guide 
Lines below for a detailed account of how to do this. We 
anticipate that this will encourage greater exchange of data 
among NASA scientists. 
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Overview 

There are a multitude of database formats in use at NASA 
today. There are a variety of commercial and in-house data- 
base management systems, each supporting a number of data- 
bases. In addition, there are large quantities of data stored 
in sequential files; data which can only be accessed by. 
specially written programs. This situation has led to diffi- 
culties for scientists trying to access information stored in 
a different format than their own. The DAVID system was 
developed at NASA to act, in part, as a central database man- 
agement system. One could "hook-in" to DAVID various database 
management systems and DAVID could translate instructions and 
data from one DBMS to DAVID, or from one DBMS to another via 
DAVID. This "hooking-in" process is called a resident inter- 
face and is at the heart of this project. Prior to this 
project, the process of building an interface was long and 
tedious and more work than most scientists were willing to do 
to obtain data. What we have done is to streamline this pro- 
cess, first with a step-by-step guide to building interfaces 
and secondly with the beginnings of a totally automated system 
for building interfaces. We have tested our strategy on a 
number of commercial products and have found it most workable. 
The remainder of this report details various parts of our sys- 
tem. 

Work Performed 

Inner Interfaces 

As part of this project, we developed a technique of build- 
ing inner interfaces between resident and host DBMSs, and 
investigated the feasibility of our technique by designing 
and building four representative interfaces to resident 
DBMSs from DAVID. We are pleased by our results; they point 
us in the direction of a prototype for the design of fast, 
easily-developed interfaces in the future. 

We define an inner interface to a host DBMS as one in which 
the resident DBMS facilities are used only for access at the 
lowest level, i.e., the I/O of a single entity (record or 
table) . All other database operations are performed by the 
host on the data after it has been moved to buffers belong- 
ing to the host DBMS. 
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This low-level-access-only capability is used in the con- 
struction of interfaces to 1) DBMSs which support a high- 
level language interface, such as FORTRAN or C, but provide 
neither a guery language nor access at the path level ; and 
2) file systems, which contain no database processing rou- 
tines of their own. The former condition occurs in many 
network and hierarchically organized DBMSs; we describe 
interfaces to IDMS and FOCUS below, both of which possess 
these characteristics. The latter set of circumstances is 
described in our interfaces to FITS and to general files, 
both described below. 

In the inner interface technique, requests for information 
and transactions submitted via the host are processed by the 
host until the request is reduced to a call for a single row 
of a single table. At that level, the request is handled by 
the DBMS under which the data is sitting. If the request 
includes a boolean evaluation, the boolean is performed by 
the host on the data after it has reached the host buffer. 
The routines in an inner interface include a set of access 
routines, and a set of opening and closing routines. 

Accessing and Transaction routines . There are a set of 
routines that perform low-level access on records (tables) 
of the database which form the building blocks of the inter- 
face. 

First. The first row of a table of the resident database is 
read into a buffer of the host DBMS. Any boolean evalu- 
ation is done in the host buffer. 

Next. The next row of a table of the resident database is 
read into a buffer of the host DBMS. Any boolean evalu- 
ation is done in the host buffer. 

Insert , Delete , Update. A row of data in the resident data- 
base is inserted, deleted, or updated. 

Connect. A row of data which has just been inserted into a 
table in the resident database, is connected to the proper 
parent. This routine only has applicability in a database 
system of network structure. 

Disconnect. A row of data is disconnected from the desig- 
nated parent and, if this is the last parent, the row is 
deleted from the database. This routine only has 
applicability in a DBMS of network structure. 
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Parent. Given a row of a table, and the name of a parent 
table of that table, this routine returns a row of data from 
the parent table. This routine only has applicability in a 
database of network structure. 

Assigning (opening) and Deassigning (closing) Resident Data- 
bases. Before table-row routines can access a resident 
database, certain initialization functions must be 
performed. Similarly, after table-row access to a resident 
database has occurred, some termination functions must take 
place before the resident DBMS is exited. These include: 

Assign Database. This routine performs "housekeeping" func- 
tions necessary to allow the resident to communicate with 
the host: it establishes the necessary data buffers and 

variables needed by the resident, logs on to the resident 
DBMS, provides the necessary security, and opens the resi- 
dent database. 

Deassign Database. This routine perforas "housekeeping" 
functions necessary to terminate host interaction with a 
resident: it closes the resident database, logs off of the 
resident DBMS, and deallocates any special data areas set 
aside by Assign Database. 

In our research, in order to investigate the feasibility of 
the inner interface approach, we designed and built four 
interfaces. These are described below. The first two, FITS 
and general files, fall into the category of file systems, 
i.e., they have no DBMS capabilities at all. The last two, 
FOCUS and IDMS , are both full-fledged DBMSs? one (FOCUS) 
hierarchical in organization, one (IDMS) network in organi- 
zation. Although IDMS has an on-line query facility, OLQ, 
and FOCUS has a 4th generation front-end, we bypassed these 
facilities to implement these interfaces. 

We chose FOCUS and IDMS because each was representative of a 
class of DBMSs, i.e., network and hierarchical DBMSs. We 
felt that in solving the problems inherent in building inner 
interfaces to systems with each of these kinds of data orga- 
nizations, we would learn a lot about how to deal with other 
DBMSs of similar organization. 

We chose the FITS and general file systems to interface 
because they represent a large portion of the data currently 
being held at NASA for analysis, and we felt that interfac- 
ing them to a DBMS would make a real contribution to the 
scientific community. 
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All four of the inner interfaces are described in the text 
below. 

FITS interface 

FITS (Flexible Image Transport System) is a file inter- 
change standard developed by a group of scientists inter- 
ested in the exchange of astrophysical data. It provides 
a simple but powerful mechanism for the unambiguous 
transmission of large data arrays and of catalogs 
describing that data. The FITS format has been adopted 
for the transmission of astronomical image data by sev- 
eral large observatories including the Very Large Array, 
the Westerbork synthesis telescope, the Kitt Peak 
observatory and the Anglo-Austral ian observatory. It is 
fast becoming a standard for the cataloging and transmis- 
sion of astronomical images and their catalogs. 

FITS files consist of a set of header records describing 
the data in the file, followed by the data itself. The 
header information is used by application programs which 
read the data. Figure 3 contains a typical FITS file 
header for a star catalog. It should be noted that by 
"header", we do not mean operating-system-specific infor- 
mation associated with a file; file access routines deal 
with those. We are referring to information contained in 
the first few records which describe the data in the 
remaining records. The header information is strictly 
for the interpretation of the data. 

The FITS file system is not a DBMS. The access and inter- 
pretation of FITS data is performed by a set of FORTRAN 
routines which are either "home grown" or shared by other 
sites among the astrophysics community. There is no 
query facility supplied for FITS data and catalogues; nor 
is there a browsing tool. Users of FITS cannot interface 
FITS data with that of any other file or database system. 

We have developed an interface technique for FITS files, 
and have used the technique to connect the FITS file 
system to the DAVID system. The effect of this is to 
provide FITS users with a SQL-like query language front- 
end, so that they can perform selection-projection opera- 
tions on FITS data. They can select certain records and 
fields from those records, applying boolean conditions on 
the operations, and forming new files or databases for 
the results (the results can be stored as FITS files, as 
DAVID databases, or even represented in another database 
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system, such as ORACLE or INGRES) . More important, data 
from FITS files can be JOINed on some common trait with 
other FITS files, with DAVID databases, and with data 
from other commercially available DBMSs, thereby giving 
scientists access to data never before available. 

The components of a FITS interface are described below. 

Defining and Deleting FITS Files through an Interface 

These routines define and drop FITS files through the 
host DBMS (here, the DAVID system) , and establish and 
break the connection between the host DBMS and the FITS 
file. 

For a FITS file to be "defined" to the host DBMS, a 
database definition must be supplied to the host's 
database directory. For the file to be "dropped", the 
definition must be expunged from the host. In neither 
case is the data changed in any way. 

Our FITS interface treats the FITS file header as a 
database schema, from which the description of the 
attached data can be derived. Our software reads the 
FITS header; then translates it into a host DBMS defi- 
nition. Any information in the FITS header not used by 
the DAVID system is preserved in the DAVID definition 
by being represented as a comment in a special format 
in the DAVID definition. That way, if the user wants 
to create another FITS file containing all the attrib- 
utes of the first one by issuing a "SELECT * " (select 
and copy all information in the file) query, the 
attributes of the first file can be obtained from the 
DAVID definition. 

After our software constructs the required definition, 
it installs that definition onto the DAVID system. The 
host then "knows about" the FITS file, and it can be 
processed like any other database; questions and 
reports in the form of queries can be solicited from 
it, the browsing tool can read it a record at a time, 
and data can be inserted into it via a query. 


Query and Transaction Processing through an Interface 

The records of a FITS file are accessed through the 
host DBMS a row at a time, using the first and next 
FITS file access routines built by us as part of the 
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file interface and linked into the DAVID system. To 
process a query on a FITS file, the query must first be 
decomposed into its primitive parts, optimized, and 
translated into a set of subroutine calls to be issued 
on the file. 

At the lowest file-access level, FITS file access rou- 
tines are identical to those of general files, 
described below. 

File interface 

A file can be defined as a related collection of data 
stored on some external electronic medium such as a disk 
or magnetic tape. Files in general differ from the 
description of FITS files, above, only in that they do 
not possess a header containing their descriptions, or 
record layouts. The descriptions of files generally exist 
in some documentary form. 

Once interfaced to a DBMS system such as DAVID, these 
file could be treated as if they were databases: they 
could be queried, selection-projections can be performed 
on them, and they can be joined with information from 
other database systems. They can also be converted into 
other representations, such as DAVID or another DBMS. 

Defining and Deleting Files through an Interface 

These routines define and drop files through the host 
DBMS (here, the DAVID system) , and establish and break 
the connection between the host DBMS and the file. 

For a file to be "defined" to the host DBMS, a database 
definition must be supplied to the host's database 
directory. For the file to be "dropped", the defini- 
tion must be expunged from the host. In neither case 
is the data changed in any way. 

The problem of creating a database "schema" for a gen- 
eral file is approached differently than it is for 
FITS; instead of decoding an existing header, the 
system must rely on the user to provide the description 
of the file. This can be done in one of two ways in 
our system: via a DEFINE statement in DAVID'S query 

language, or via an interactive session with DAVID'S 
browsing tool. In either case, the submission of the 
definition triggers an interactive session with the 
user, in which he/she is asked to provide any informa- 
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tion required by the host system but not provided by 
the definition (in the case of DAVID, such information 
as column numbers for the individual fields, and data 
types not available on the DAVID system) . After the 
definition is solicited, software constructs the 
required definition. 

Query and Transaction Processing through an Interface 

The records of a file are accessed through the host 
DBMS a row at a time, using the first and next file 
access routines built by us as part of the file inter- 
face and linked into the DAVID system. To process a 
query on a file, it must be decomposed into its 
primitive parts, optimized, and translated into a set 
of subroutine calls to be issued on the file. 

Figures 4 through 8 illustrate the use of the file 
access routines to access a general file. The examples 
are written in C, for a file on a SUN 4 computer under 
UNIX. Figure 4, assign database, performs the prelimi- 
nary tasks on the file so that it can be read through 
the host DBMS. Note that instead of opening a 
database, this routine opens the file. Figure 5, 
table-row first and table-row next, provides the host 
with the capability of reading a record at a time of 
the resident. Figure 6 provides for inserting one 
record a time and figure 7, Deassign File, illustrates 
closing the file and performing any other necessary 
housekeeping routines after file processing is fin- 
ished. 

The IDMS Database Management System Interface 

The IDMS Database Management System, developed by the 
Cullinet Corporation, is a network-structured DBMS that 
runs on a variety of manufacturers ' equipment, including 
the IBM 327x series, and the DEC VAX series. Later ver- 
sions contain a query language (0I£) as well as the tra- 
ditional access methods, via IDMS calls embedded in an 
applications program written in PL/I, COBOL, C or 
assembler. 

IDMS was chosen for our research because it is repre- 
sentative of a class of DBMS systems, namely those that 
conform to the standards set by the Database Task Group 
of the CODASYL Committee for database systems. These 
DBTG systems, as they are often known, support network 
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database organization, and have 3 languages: a schema 

data description language (DDL) , a subschema data 
description language (DML) and a data manipulation lan- 
guage (DML) . The schema languages are distinctly COBOL 
in flavor, since that was the committee's orientation 
(they were an outgrowth of the original designers of 
COBOL) and the data manipulation language consists of 
calls to be embedded in a language such as COBOL or PL/I. 
Compared to the query facilities of many of today's lan- 
guages the DML seems quite cumbersome? however, it was 
the perfect vehicle for building an inner interface to a 
host DBMS. N.B. Because the DAVID system is not yet 
available on the platform on which IDMS runs, this inter- 
face puts the data into the host buffers, from which it 
is displayed. 

Defining, Installing, Dropping and deleting IDMS data- 
bases through an interface 

In IDMS, as in other resident DBMSs, we distinguish 
between the Define operation and the Install operation. 
Define creates a new IDMS database via the host sys- 
tem. To create the definition, the user, sitting at 
the host DBMS front end, submits it in the host 
query/definition language. Software from the interface 
then translates the definition into an IDMS schema and 
subschema representation and submits it to the IDMS 
DBMS, where it defines a new database in IDMS. The 
corresponding host definition submitted by the user is 
then added to the collection of database definitions 
belonging to the host DBMS. 

Install, on the other hand, is used to connect existing 
IDMS databases to the host DBMS, so that they can be 
processed via the host. In the Install operation, the 
IDMS schema is read, and software creates the corre- 
sponding host database definition; then it adds the 
definition to those of other resident and non-resident 
DBMSs so that the host software can access the IDMS 
database system. So the Install operation is used when 
a user wants to be able to access an existing IDMS 
database through the host DBMS; the Define operation is 
used when the user is creating a new IDMS database via 
the host DBMS. It may appear as though the Define 
operation would be used less often than the Install, 
but in fact the opposite is the case: whenever a user 

issues a query on a database stored in the host or in 
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any other resident DBMS and requests for the result to 
be stored as an IDMS database, the result is a call to 
the IDMS database definition software. 

The Drop operation does not affect the IDMS database 
being deleted; it merely breaks the connection between 
that database and the host. We can continue to do 
processing operations on the IDMS database; but they 
can only be IDMS operations; host database processing 
is no longer defined on this database. 

The Delete operation actually erases the IDMS database; 
in addition, it drops its schema from the DAVID direc- 
tory. 

Query and transaction processing through an inner 
interface 

As in the case of FITS and general files, and all other 
inner interfaces, the minimum set of operations needed 
to process queries and transactions on an IDMS database 
via the host DBMS is: open , close, first, next, and 

insert. These operations will be discussed below. 

IDMS was designed for database access via program (CO- 
BOL or PL/I) . Each query and transaction normally is 
performed by writing, compiling and linking a separate 
program specific to that query and transaction. The 
program contains references to a specific database, and 
specific records, sets (parent-child record pairs) , and 
fields in that database. For example, the declaration 
section of the program contains declarations for the 
schema and subschema of that particular database, and 
there is a set of INCLUDE statements, one for the 
database itself. The IDMS preprocessor reads and deci- 
phers these statements, and replaces them by the corre- 
sponding calls to IDMS external functions. 

Our inner interface approach requires generic routines 
with no database-specific variables; otherwise every 
routine would have to be compiled and linked for every 
query, and query processing would be far too slow. To 
get around this problem, our solution was to bypass the 
IDMS preprocessor, and replace the IDMS code by conven- 
tional calls to a linked procedure called IDMS. In 
this way we communicate with the IDMS DBMS directly 
through the IDMS assembler procedure. 
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Examples of some of these preprocessor expansions are 
(we are assuming a schema called BCCIS45 with a child 
table called TEACHER; the fields of TEACHER are 
described in the declaration) ; 

INCLUDE IDMS (BCCIS4 5-TEACHER) . 
is replaced by; 

DECLARE 1 BCCIS45_TEACHER, 5 
TM_CIS45_TCHR_ID_NUM CHARACTER (6), 5 
TM_CIS45_TCHR_FULL_NAME, 10 
TM_CIS45_TCHR_LST_NAME CHARACTER (15), 10 
TM_CIS45_TCHR_FST_NAME CHARACTER (10), 5 
TM_C I S 4 5_TCHR_S 0C_S EC_NUM CHARACTER ( 9 ) , 5 
TM_C I S 4 5_TCHR_RANK_CD CHARACTER (1),5 
FILLER0002 CHARACTER (7) ; 

The preproccessor replaces the code: 

INCLUDE IDMS ( SUBS CHEMA_CTRL) . 
by: 

DCL 1 SUBSCHEMA_CTRL STATIC BINARY, 3 
PROGRAM CHARACTER (8) INITIAL (' '),3 
ERROR_STATUS CHARACTER (4) INITIAL ('1400'), 3 
DBKEY FIXED BINARY 3 

RECORD_NAME CHARACTER (16) INITIAL (' '),3 
AREA_NAME CHARACTER (16) INITIAL (' '),3 
ERR0R_SET CHARACTER (16) INITIAL (' '),3 
ERROR_RECORD CHARACTER (16) INITIAL (' '),3 
ERROR_AREA CHARACTER (16) INITIAL (' ' ) , 3 
I DBMS C0M_AREA , 5 

I DBMS COM (100) CHARACTER (1),3 
DIRECT_DBKEY FIXED BINARY (31), 3 
DATABAS E_S TATU S ,5 
DBSTATMENT_CODE CHARACTER (2), 5 
DBSTATUS_CODE CHARACTER (5), 3 
FILLER0001 CHARACTER (1),3 
RECORD_OCCUR FIXED BINARY (31), 3 
DML_SEQUENCE FIXED BINARY (31) ; 

DCL 1 RECORD_NAME 

BASED (ADDR(SUBSCHEMA_CTRL. RECORD NAME) ) 

STATIC INTERNAL, 3 ~ 

SSC_NODN CHARACTER (8), 3 
SSC_DBN CHARACTER (8) ; 
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In our strategy , we bypass the preprocessor, and 
replace the expanded calls by generic calls which can 
be parameterized, so that all information can be 
supplied to the interface routines at run time. So 
instead of a schema declaration with actual field names 
to replace the INCLUDE IDMS statement, we use a dynamic 
allocation with the fields supplied at run time. In a 
similar vein, all the expansions are established m 
such a way that no information is database-dependent. 

Below we describe the same process with database access 
operations. 

How do we open IDMS: 
replace: 

INCLUDE IDMS (SUBSCHEMA_BINDS) . 


by: 

SUBSCHEMA_CTRL. PROGRAM = name; 
replace: 

BIND RUN UNIT. 


by: 


SUBSCHEMA CTRL. DML_SEQUENCE = SEQUENCE; 

CALL IDMS ( SUBS CHEMA_CTRL , IDBMSCOM ( 59 ) , SUBSCH- 


EMA CTRL 


, SUBSCHEMA_NAME) ; 


IF ( ERROR_STATU S <> '0000') THEN DO; 
STATUS_CODE = ERROR_STATUS ; 

GOTO END_STATUS; 

END; 


replace: 

READY RETRIEVAL. 


by: 

SEQUENCE := SEQUENCE + 1; 

SUBSCHEMA_CTRL.DML_SEQUENCE = SEQUENCE; 

CALL IDMS (SUBSCHEMA_CTRL, IDBMSCOM (37)); 

IF ( ERROR_STATUS <> '0000') THEN STATUS_CODE = 
ERROR STATUS; 
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The open operation for IDMS, then, consists of a set of 
generic preprocessor calls to which database— specif ic 
information is passed as parameters. It includes all 
the declarations of variables, statements to bring up 
IDMS, to open and ready the specific database and 
schema areas, and to establish the error— reporting 
mechanism, and the mechanism to retain currency infor- 
mation while navigating through the database, so that 
"give me the next record" has some meaning. It also 
sets up bindings to buffers into which the data will be 
transferred so that the host DBMS can pick it up. 

When a user opens an IDMS database, the host system 
®®ust establish a memory data structure for keeping 
track of the IDMS operations and their status. It also 
contains buffers for any data to be transferred to the 
host system. Each user wishing to access an IDMS data- 
base must open IDMS separately. Therefore there will 
be a separate memory data structure for each set of 
IDMS processing operations taking place. These memory 
data structures are used to communicate between the 
embedded IDMS processing calls, which are widely scat- 
tered through the host system, sometimes separated by 
la yers of functions through which the structures must 
be passed. (In a totally IDMS environment, these prob- 
lems do not arise; since each IDMS user is running a 
separate program, many of these data areas can be 
global.) All of these data areas had to be added to the 
collection of host DBMS data structures. Because it was 
clear that this situation will arise in all DBMSs of 
this class, and in some of other classes as well, these 
data structures were made as generic as possible, and 
only a pointer to one of them was stored in the DAVID 
cluster control area in the current implementation. 

The first operation and the next operation both contain 
function calls to the corresponding IDMS external 
functions to correspond to the IDMS language calls 
OBTAIN FIRST RECORD (name) SET (set_name) and OBTAIN 
NEXT RECORD (name) SET (set name) 

The operations first and next have a different meaning 
in hierarchical and network database systems than they 
do in the context of relational database systems and 
files. In a "flat" database (with no parents or chil- 
dren) the meaning of "next record" is unambiguous. In 
database systems where there are child tables and 
parent tables, and particularly in network database 
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systems where there can be multiple parents for a 
single child table, the request for a "next" record 
must supply the identity of the parent of that record, 
and keep track of the current owner at all times. 

The close operation contains IDMS function calls to 
close the database and check the error status of the 
preceding operations. It must also perform such 
"housekeeping" functions as deallocating the storage 
for the data structures used in processing the data- 
base. After a close has been executed for a particular 
IDMS database, no further processing of that database 
can occur unless another open command is first issued. 

The code for the IDMS database access operations 
appears in the appendix. 


FOCUS Interface 

The FOCUS Database Management System, developed by Infor 
mation Builders, Inc., is a hierarchically structured 
DBMS that runs on a variety of platforms, including an 
IBM personal computer and several mainframes. There is 
an upload/download facility, whereby database information 
can be transmitted from a PC to a mainframe and vice 
veers. FOCUS has no query language per se; however, a 
menu-driven 4th generation language front end is avail 
able on the PC version to aid the user in building 
reports and requesting transactions. FOCUS databases can 
also be accessed and updating using HLI (Host Language 
Interface) commands, a set of function calls which can e 
embedded in high level language programs. 

FOCUS was chosen for our research because of the fact 
that it is a hierarchically structured DBMS which runs on 
a wide variety of computers; also because we feel it is 
representative of a class of database systems , 1 . e . , 
those which support tree-structured data organization. . 
Our interface did not use the menu facilities of FOCU , 
rather it was constructed of calls to the FOCUS HLI rou- 
tines for the retrieval of information. Those routines, 
which are generic for the processing of any database, can 
be linked into the host system a single time; then 
instantiated for a specific database via parameters 
passed to the routine. N.B. Because the DAVID system is 
not yet available on the platforms on which FOCUS runs, 
this interface currently puts the data being retrieve 
into the host buffers, from which it is displayed. 
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FOCUS databases are made up of a series of files, each 
containing a logical record of the database. The files 
(records) are connected by pointers. The interface loads 
HLI (the FOCUS host language interface routines) and 
accesses multiple files dynamically. In the interface, 
files can not be opened more than once even though 
HLI allows it. The number of files that can be 
opened concurrently is limited only by the amount of RAM 
memory . 

Defining, Installing, Dropping and Deleting FOCUS Data- 
bases via an Interface 

Like that of its counterpart, the network DBMS, the 
Define operation for a FOCUS database consists of 
translating a host database definition into a set of 
FOCUS definition calls that are then used to create a 
new FOCUS database (called a "master file" in FOCUS) ; 
the host version of the database definition is then 
entered into the host's database directory. The 
Install operation translates an existing FOCUS database 
definition to a corresponding host definition for the 
same FOCUS database. That definition is stored, as it 
is in the Define operation, in the host's database 
directory. The difference between the Define and the 
Install operation is that Define is for new databases; 
Install is for existing FOCUS databases to be connected 
to the host system. 

For the Install operation, the FOCUS Master File 
Description (schema) is parsed; then the corresponding 
host definition is generated. Fields that do not hold 
data meaningful to the host (such as OCCURS COUNTER 
fields) are ignored in the translation process. A 
master file description contains file attributes, seg- 
ment attributes and field attributes. The file attrib- 
utes appear once in a master file description, and 
contain information about the physical file, which maps 
to the database name for the host. The segment attrib- 
utes supply information about the parent relationships, 
which is what gives FOCUS its hierarchical structure. 
The field attributes correspond to the individual 
fields of records of any file or database. There are 
many parameters describing each field in a FOCUS data- 
ksse; those which are meaningful to the host are trans- 
lated to the host data definition; those which are not 
are ignored. 
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The Define operation does the reverse: it creates a 
FOCUS master file description from the host database 
definition. This description will of necessity contain 
very few FOCUS field parameters; only those which can 
be defined in the host DBMS will be carried over; the 
result is a "vanilla" FOCUS master file description. 

The Drop operation simply removes the host's version of 
the FOCUS database definition from the directory; the 
FOCUS database is left alone, but it can no longer be 
processed via the host. The Delete operation performs 
a Drop; it also erases the actual FOCUS database. 

Processing Queries and Transactions via an Inner Inter- 
face 

As in other inner interfaces discussed here, an inner 
interface between FOCUS and the host DBMS reguires five 
major components: open, close , first , next and insert. 

In order for the interface to deal dynamically with 
databases, it must maintain a memory data structure 
that contains data about the names, type, and length of 
each field in the database (a full view of the database 
is applied) . These mapping tables are allocated from 
memory and stored in linked list form. Every opened 
file has a linked list, and every file is identified by 
an index of linked lists. These are referenced by 
the array list which is an array of pointers to lists. 
The main elements of a list are HLI system struc- 
tures of the type INFOF, which is a structure that 
holds information about one field in the file. These 
structures are linked together by a structure that has 
two pointers: one pointer to INFOF structure, and a 

second pointer to the next structure. 

Each file has an entry in an array of files called 
filename[], and a flag, open_flag[], that has a true 
value when the file is open. For each file a work 
area is allocated dynamically as a character string. 
When a retrieve operation is done such as get first 
record, the data that HLI stores in the work area can 
be retrieved by using the mapping tables stored in the 
linked list. When a file is closed, all the memory 
that was allocated for it is released. 
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So the open inner interface operation invokes FOCUS 
(N.B. The PC FOCUS product can be made to become 
memory-resident when it is invoked. So the more likely 
scenario is to make it continuously memory-resident; 
another option is for the open to make it memory- 
resident. In this case it will reside in memory only 
until the close removes it. In either case its status 
must be checked; attempts to start up an already 
memory-resident process can lead to unpredictable 
results! 

The open operation also performs some house-keeping 
chores. The following is a representative set of these 
chores: it allocates a work area for the data being 

retrieved, it builds a control area for the opened 
database by creating field mapping tables; it allocates 
a file control block for the database 

As in the network DBMS described above, first and next 
have different meanings in hierarchical database sys- 
tems than they do in relational systems or flat files. 
Both operations call upon the generic HLI function call 
M get_seg" , which accepts as parameters the information 

database operation (first, next, etc.) 

database name 

segment to be retrieved 

parent of segment to be retrieved 

and retrieves the required information. The database 
name, segment name and parent segment name are supplied 
by the host system as the request for data is issued by 
the host system. The "currency", or the proper parent 
for each segment, is kept in the work area allocated at 
open time. The choice of database operation is deter- 
mined by the calling host routine. 

The close operation closes the focus database and, if 
FOCUS itself is not to be memory-resident, removes it 
from memory. It also deallocates the many work areas 
and temporary files set up to process the FOCUS data- 
base. 

Summary and Evaluation of the Inner Interface Method 

The inner interface method proved to be a workable 
method for building interfaces; indeed, it is the only 
feasible way to build interfaces to those DBMSs with no 
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query or path access facilities. It gives great power 
to a resident DBMS — all the power of the host DBMS — 
with just the coding of a few routines, and is, from a 
computing resources point of view, by far the more 
efficient method for an interface than the alternative 
method, by which a batch job containing data-base spe- 
cific requests is created, then compiled and linked, 
then executed. We rejected the latter approach 
out-of-hand when a few preliminary tests showed it to 
be intolerably slow. 

Moving most of the processing that the resident data- 
base performs on the records (such as boolean evalu- 
ation) to the host from the resident will generally 
improve performance over that of a similar operation on 
the resident DBMS alone; the host system is designed 
for faster processing than many of the older DBMSs. 

However, there are difficulties with the inner inter- 
face approach. For each interface, a total of about 15 
routines must be compiled and linked to the host 
system, and the resulting system must be debugged and 
tested. The potential for error is great, and the 
interface builder must be an experienced programmer. A 
contrasting approach is presented in the next section, 
in which we discuss outer interfaces. 

Outer Interfaces 

For database systems with query languages, a very fast way 
to build interfaces is using the outer interface approach. 

In this method, the Define , Install , Drop and Delete work 
the same way as the same operations in the inner interface 
method. However, the query and transaction processing 
interface component is quite different. 

When queries are submitted to the host system, they are 
parsed; then translated into the query language of the resi- 
dent system. The query is executed on the resident, and the 
results are captured to a file, which can then be read by 
the host system by a single standard inner interface. 

This method of building interface is particularly attractive 
because it is so straightforward; we have designed an expert 
system to facilitate their construction. Using this system, 
a person familiar with a resident DBMS can build an inter- 
face in a short amount of time, sitting at a personal com- 
puter. No programming is required. 
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The outer interface construction process uses an approach we 
call the template approach; its components are explained in 
detail in a subsequent section. Briefly, here's how it 
works: Each database operation for every DBMS is depicted 

in a block of text called a template. The template contains 
DBMS -specific commands, such as CREATE, or SELECT, or OPEN, 
and symbols for data-base specific information: for exam- 

ple, the name of a table would be replaced by the symbol 
Gtablename. 

Here is a sample template for creating a single table in the 
ORACLE database system: 

CREATE TABLE @tablename ( 

0BEGINFIELDS 

<,><><> Gfieldname 0fieldtype Gfieldlength 
0ENDFIELDS ) 

The symbols beginning with H @BEGIN " And "§END..." Connote 

loop structures for repeating text; the symbols <><><> con- 
note left and right delimiters and separators for repeating 
text. 

At execution time, the template is filled in by replacing 
the symbols (those beginning with §) with database-specific 
information. The result is an executable module which per- 
forms the required database operation. 

The template approach is used for all outer interface compo- 
nents; it is used also for the inner interface components 
Define , Drop , Install and Delete. Only the inner interface 
database access and transaction processing operations first , 
next , open , close, and insert have to be individually coded, 
since they have so many idiosynchratic requirements. 

Summary and Evaluation of the Outer Interface Building 
Approach 

Outer interfaces have a clear advantage over inner ones 
in their construction; an outer interface requires no 
programming, and can be designed by a person knowledge- 
able about the resident DBMS to be interfaced but with no 
knowledge of the host DBMS. The designer can design the 
entire interface sitting at a personal computer. 

There are two disadvantages to the outer approach: one is 
that it can only be used to design interfaces with DBMSs 
that have query languages. The other is that there is a 
great deal of overhead associated with the fact that the 
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data is captured to a file before it can be processed by 
the host system; in the case of very large databases, the 
storage and processing requirements to do this can be 
prohibitive. 

A large portion of our research has been devoted to the 
design and construction of an expert system to aid the 
designers of outer interfaces in building the templates; 
this simplifies the process of interface building even 
more, because the builder has a great deal of help in 
his/her task. The expert system, which we have called 
TGS (the Template Generator Software) will be described 
in the next section. 

There is also a set of Interface Guidelines (see the 
section of the same name below) . This document is 
intended to serve as an aid to the builder of any inter- 
face, inner or outer. It "walks" the user through the 
process, from the determination of the type of resident 
interface is being built, through the design, construc- 
tion and testing of the interface routines. The document 
can be used without the expert system, or as a supplement 
to it. 
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Front-end Processor 

The first of the two major pieces of software involved in 
the DIDS project is the front-end processor which we have 
called Template Generator Software (TGS) . When a user 
wishes to build an interface for a given DBMS, he/ she must 
first run the front-end processor to tell the system the 
relevant information about that DBMS. This information . is 
solicited through a dialog with the user. The TGS continu- 
ally guides the user by asking a series of questions about 
the DBMS in question. 

Detailed information concerning installation and running of 
the software as well as the relevant tables (files) gener- 
ated by these programs can be found in the appendices. 

The TGS is an interactive software package which infers tem- 
plates from user input. The user describes how specific 
examples would be written in his/her own native database 
language, and the software infers the syntax of the language 
using techniques largely based on artificial intelligence. 

The software is segmented to allow separate user sessions, 
each user session generating a specific type of template for 
the user's database language. It is only assumed that the 
user is knowledgeable about his/her own database language. 
Nothing is assumed about knowledge of DAVID templates, and 
the user is not asked to answer any questions which require 
knowledge about templates. For information's sake only, 
portions of the template being generated are displayed as 
the reasoning progresses. 

The separate sessions are invoked by separate modules. The 
various sessions which can be invoked are: 

1. A session to generate separate log-on and log-off 
templates for a session in which a user wants to define a 
database, using either the inner or the outer approach. 

2. A session to generate a template for defining a 
database in the user's native database language. There are 
actually two modules built for this purpose: 

2a. One which allows a user to describe how one 
defines a database in a relational database language. 

2b. Another which allows a user to describe how 
one defines a database in a hierarchical or network data- 
base language. 
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3. A session to generate separate log-on and log-off 
templates for a session in which a user wants to access a 
database which already exists on the system (the Install 
operation) . 

4. A session to generate a query template for a session 
in which a user wants to enter a query against a database. 
(This session can be used only in the design of outer inter- 
faces. ) 

A session of type 1 must be run before a session of type 2 , 
because the template generated during a session of type 2 
includes the log-on and log-off protocols elicited from the 
user in a session of type 1. Similarly a session of type 3 
must be run before a session of type 4. Otherwise the 
sessions are completely independent. 

These modules generate tables along with templates when such 
tables are needed to supply additional information. The 
software runs on IBM PC compatible computers with 64 OK of 
main memory and a hard disk. At the completion of a session 
the templates and associated tables are stored on the hard 
disk so that they can be retrieved at the user's conve- 
nience. 

This expert system tool can be used to design all components 
of outer interfaces; it can also be used to design the 
Define, Delete, Install and Drop components of inner inter- 
faces. 

Interface Driver program 

The second software component of the DIDS system is the 
Interface Driver. Recall that a template is a block of text 
designed to capture all the syntax of a DBMS command without 
the actual database-dependent data. The TGS, described 
above, creates a template with DBMS independent items (names 
the items preceded with "@") . The Interface Driver is the 
software component that replaces all the ,, §" commands with 
DBMS specific language at run time. Thus the TGS is inde- 
pendent of all DBMSs, while the Interface Driver fills in 
the DBMS -dependent information into the output of the TGS. 
From the templates generated by the TGS and other syntax 
dependent tables generated by the TGS (see appendix 2) , it 
creates a "f illed-in M template which can be used directly by 
the DAVID system. See figure 1 for the over-all organization 
of this module. 
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Figure 1: Interface Module Architecture 



The following 3 constructs are descriptions of items in Ficr- 
ure 1 . ^ 

(1) NEXT-GSQL: This is a DAVID data structure that contains 

query-specific data to be translated into resident DBMS syn- 
tax. This structure is filled in by DAVID and passed to the 
Interface Drive. 

(2) Templates: For each database operation (e.g., define, 

selection-projection, etc.) there is a template describing 
the syntax of that operation in that DBMS. The selected 
template will be filled by the template— filling algorithm 
which is the main element of the Interface Driver. The 
result is a module which performs the given operation for 
the given DBMS. These modules are executed by the DAVID 
system in a timely fashion. 

(3) Other Syntax-Dependent Files: For each DBMS, there may 

be some DBMS dependent information required to complete the 
template generation. For example, in translating a DEFINE 
statement, on needs to know the corresponding type name of 
say INT, in the resident DBMS. The type name may be INTEGER 
or 1 or "numeric" etc. This information is found in the 
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type conversion table * This table and others is stored in 
files generated by the TGS- Contents and format of these 
files can be found in Appendix 4. 

> 

Template Design 

A template is a block of text that captures all the syn- 
tax of a DBMS command without the actual data. Because a 
template does not contain any actual data, we need some 
special symbols to define the syntax of the template. In 
this section, we discuss the syntax of the templates. 

General Syntax 

[1] ©-Sign: Any token that begins with an ©-sign is a 

special command, to be processed by the software. 
Either it is replaced by a piece of data, or by a 
loop construct in the completed code. Symbols 
which are not prefix by ©-signs are considered to 
be constants . 

[2] Whitespace: Any ©-command should be terminated by 

a whitespace (blank, newline, tab) . This white- 
space terminator is consumed during the scanning 
process and does not appear in the filled template. 
All other blanks will be echoed as regular charac- 
ters. 

[3] Back Slash: The back slash character (\) is a 
metacharacter that has special meanings. To have 
it in the (output) string, one must use \\ to 
override it. Thus "\\" is equivalent to " \ M • In 
general, "\c" is equivalent to "c" for any charac- 
ter c NOT equal to "n" . See [4] for the meaning of 
"\n" . This provides a way to generate the actual 
character M @ M in the filled template ("\©" ) • 

[4] End-of-Line: Any "physical" end-of-line shall be 

ignored by the template— filling program. Instead, 
"\n" is used to break up the filled template into 
lines. In other words, the physical end-of-line in 
the template are there to make reading easier. It 
has nothing to do with how the filled template 
should look. (The filled template gets its line 
spacing from the back slash n character) . 
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Substituting Commands 

The syntax for the substituting commands is given 
below: 

§<name> [ -<seq . no . > ] 

where <naxne> is a string of UPPERCASE letters of length 
one or more, and the <seq.no.> is a positive integer. 
The sequence number is optional with a default value of 
one. A list of substituting commands and their defini- 
tions can be found in Appendix 7. The command names can 
be changed. To do so, the corresponding names in the 
template and the Build_hash_table function have to be 
changed to exactly the same name. 

Repeating Commands 

The syntax for the repeating commands is given below: 
§BEGIN<namexdelimiters> 


@END<name> 

where the <delimiters> is defined as 

["<" , separator> ["><" <L-delimiter> "><" 
<R-delimiter>] ">"]. A list of all repeating commands 
and their definitions can be found in Appendix 7. The 
command names can be changed. To do so, the corre- 
sponding names in the template and the Build_hash_table 
function have to be changed to exactly the same name. 

Program Structure 

A brief description of the structure of the program is 
given in this section. Figure 2 below shows a general 
organization of the interface module. Oval blocks indi- 
cate program modules. Rectangular blocks are data 
f iles/structures . Those rectangular blocks with double 
edges are internal structures. A description of each 
file included in this module is given below. 
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Figure 2: Interface Module Program Organization 



david.c 

This is the main driver of the module. In includes two 
header files gsqlrow.h and template. h. The main algo- 
rithm is stated below: 

-Select and Open the Template 

-Build a syntax tree using the Template 

-Create a GSQL-ROW structure 

-Select and open the Type-Conversion table 

-Traverse the GSQL-ROW structure 
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-Select the information needed to fill in the tem- 
plate. 

For type information call the type conversion func- 
tion. 

Build the hash table to store all selected informa- 
tion. All future references to the data is via the 
hash table. 

-Open an output file 

-Generate filled template 

gettemp . c 

This file contains a function to open a template file. 

tree . c 

The file contains two major functions dealing with syn- 
tax trees. The first, BUILDTREE, builds the syntax 
tree using the template. The second, (GENERATECODE) 
fills the template using the syntax tree and data from 
the hash table. 

gettable.c 

This file contains a function that reads the type con- 
version file and stores the information in an internal 
type conversion table for later use. 

buildht.c 

This file contains routines that build the hash table. 
The main body of the file walks through the GSQL-ROW to 
select the information neeeded to fill the template. 

For type information (name, length, precision, etc.), a 
call to the type conversion function is needed. Build 
the hash table to store all selected information. All 
future reference to the data is via the hash table. 

typeconv.c 

This file contains two functions involved in dealing 
with type conversion. 


Contract NASS 30304 - Final Report 


Page 29 



Report Body 


utility. c 

This file contains several utility routines used 
throughout the module. 


Contract NAS5 30304 - Final Report 


Page 30 



Report Body 


Guidelines for Interfacing Resident DBMSs to the DAVID Sys- 
tem 


Introduction 

These guidelines are intended to serve as an aid to the 
interface developer. Using these guidelines, an inter- 
face developer should be able to design, build and test a 
complete resident database management system interface. 
The aid of the host DBMS database administrator is 
required for installation of the software generated with 
the help of these guidelines. 

These guidelines can be used to design interfaces to any 
kind of DMBS . For designing outer interfaces (see expla- 
nation below of outer interface) the developer need not 
be a programmer; familiarity with the resident DBMS to be 
interfaced with the DAVID system is sufficient. To 
develop inner interfaces (see explanation below) , pro- 
gramming ability is required. 

The DAVID System 

Here, we describe the DAVID database management system, 
and outline the process of interfacing your database man- 
agement system (DBMS) to DAVID. 

What is DAVID? 

The Distributed Access View Integrated Database (DAVID) 
system is a heterogeneous distributed database manage- 
ment system currently under development at NASA's God- 
dard Space Flight Center. It is heterogeneous, meaning 
that its database structure, called a cluster , supports 
databases with relational, hierarchical or network 
structures. It is a distributed system, and can run 
simultaneously on a variety of computers communicating 
via a local area network and/or a variety of wide area 
networks. It has its own query language, GSQL, and 
also provides data access through a number of high- 
level programming languages such as C, PASCAL and FOR- 
TRAN. In addition to access via query language and 
high-level programming language, DAVID provides 
on-line interactive software for browsing through data- 
bases and performing transactions. 
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What is an Interface to the DAVID System and what is it 
used for? 

An interface to the DAVID system consists of a set of 
software routines connected to the DAVID software, 
which allow the data from databases in your DBMS to be 
processed via DAVID. Once a DBMS has a set of inter- 
face routines linked into DAVID, any database in that 
DBMS can be accessed via DAVID (provided, of course, 
that its owner grants permission) . Data from your DBMS 
can be stored into DAVID, and DAVID data can be stored 
in a database belonging to your DBMS. 

Why would you want your DBMS to be interfaced with 
DAVID? 

By building an interface between the DAVID system and 
your DBMS, we can provide your DBMS with the capabili- 
ties of the DAVID system: Queries can be issued on 

your data using the DAVID query language, DAVID access 
routines can access your data, and data from DAVID can 
be stored into a database on your DBMS and vice veers. 
This gives access capabilities to your database that 
you might not otherwise have. Furthermore, you are 
now "interfaced” to any other DBMS that is in turn 
interfaced to the DAVID system. So, for example, you 
can issue queries on an ORACLE database whose results 
can then be stored in a DBMS of your choice — all 
through the DAVID system. (This assumes, of course, 
that interfaces exist between DAVID and your DBMS, and 
DAVID and ORACLE.) 

What are the Components of an Interface? 

Here, we discuss the component parts that make up a complete 
resident database interface. Depending upon the type of 
DBMS you wish to interface, different of these components 
will be used. A discussion of the types of DBMSs follows 
this section. 

Components to Define, Install, Delete and Drop a Resident 
Interface. 

These routines create new resident databases (DEFINE) , 
connect existing ones to the DAVID system (INSTALL) , 
disconnect resident databases from the host DBMS without 
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actually touching the data in any way (DROP) , and delete 
resident databases from their own DBMS as well as the 
DAVID system (DELETE) . 

DFFJWF allows the user to create a new database under 
his/her resident DBMS entirely through the DAVID system. 

U S S r create f a database definition, or schema, for a 
new database using DAVID syntax on the DAVID system. 

When the request is executed, it is translated into the 
syntax of the resident DBMS and executed; it then creates 

DAVT ; e ;.? at f abase ‘ In addition, it puts an entry into the 
DAVID directory about the newly created database, and 
enough of its schema information for DAVID to be able to 

£ he data from this database as if it were a 
DAVID database. 

INSTALL performs the second part of the DEFINE operation; 
Jr*. ls ' ^ enters information about an existing resident 

via D???n ln DAVI ? system 30 that it c an bl accessed 

via DAVID. It does not touch the database itself, which 
already exists. 

°P erat ion, then, is used to create new resi- 

abaSe f - and . te11 the DAVID ^tem about them; the 
install operation is used only to tell DAVID about 
existing databases. 

™ ;P® r ^ tion drops directory information about the 

resident da t a base from the appropriate DAVID directory; 
the database is still intact in the resident DBMS after 

execution of a drop command, but DAVID can no lonaer 
access it. ^ 

The DELETE operation does all that the DROP operation, 

tZZZZl a S° V ^ d ° e ? ; in addition, it erases the actual 
database and all of its associated data. 

® f £ h ® £°^ r operations described above exist on all 
^ databases, regardless of type. The components 

o! DBM^being 6 ^ iscussedf aCC ° rdi "« th * 

faced nentS Which de P en<1 on the type of DBMS to be inter- 

be r ?^^?LS e * eS fe ry ^ nformation about the resident must 
be instailed in the directory of the host DBMS. Once 

this has been done, queries and transactions meant for 
the resident can be submitted through the host. These 
operations are outlined in the next group of routines 
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The interaction between the resident and the host can 
take place on 3 possible levels: the query language 
level, the table level, and the path level. 


The Query Language Level 

Some resident DBMSs support their own query languages. 

For those DBMSs, a query or transaction involving a resi- 
dent submitted through the host DBMS can be translated by 
the resident interface into a query or transaction m the 
language of the resident, and then executed by the resi- 
dent in its own environment. The following primitive 
queries have been isolated as the components of any 
complex query between a resident database and a host 
database: 


Generalized Selection-Projection. A selection-projection 
or selection-multiprojection is performed on a resident 
database. The results of the query are stored m a new 
database on the host. 


Semi join. A join is performed between a resident data 
base and a host database. The result is a new database 
on the host, and a table of pointers to rows of data 
items in both the source host database and the new result 


database. 

Store-to-Database. A selection-projection is performed 
on a database on the host DBMS; the result is stored in a 
new database in the resident DBMS. 

Insert , Delete, Update. Transactions submitted through 
the host are performed on a resident database. Insert 
adds row(s) of data items, delete removes a row or more, 
update modifies a row or rows. 


The Path Level 

If the resident DBMS has a high-level language interface 
(such as C, PASCAL or FORTRAN), and supports a command to 
retrieve information from several tables of the database 
as a single access (as is often the case in a hierarchi- 
cal database) , then requests for information and transac 
tions submitted via the host can be handled by the host 
at the Path Level. The host DBMS determines the proper 
access path through the resident database? then calls on 
the path access routines of the resident DBMS to navigate 
through the resident database. These routines are. 
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Path First Row. The first path "row" of the resident 
database (i.e., the first row of every table that makes 
up the specified path through the database) is read by 
the resident DBMS, and the data inserted into the host 
DBMS data buffers. There is one host DBMS data buffer 
for each corresponding table row of the resident. Any 
boolean evaluation is performed by the host DBMS on the 
data in the buffers. 

Path Next Row , Path Previous Row, Path Last Row. The 
required path "row" of the database is read into the 
corresponding host DBMS buffers, where any boolean evalu- 
ation is done. 

Path Insert, Update, Delete. A path "row” of the data- 
base, including all of the tables specified in the path, 
is inserted, updated or deleted. 

Path Assign. This routine performs "housekeeping" func- 
tions necessary to allow the resident DBMS to communicate 
with the host at the path level: it determines which 
tables of the database must be used to make up the path, 
and allocates necessary data buffers required by the res- 
ident to contain path information. 

Path Deassign. This routine performs any "housekeeping" 
functions necessary to terminate a resident interface 
path access by disassociating the resident with that path 
if necessary, and deallocating any special data areas set 
aside by Path Assign. 

The Table-Row Level 

In some cases, it is necessary to access the resident 
DBMS at the lowest level, i.e., the Table-Row Level. 

This table-at-a-time access capability is used for those 
resident DBMSs which support a high-level language inter- 
face, such as FORTRAN or C, but provide neither a query 
language nor access at the path level. This is common in 
network DBMSs. In these cases, the only way for the host 
DBMS to process the resident data is at the single table 
level. When resident DBMSs support user access at the 
table-row level, requests for information and transac- 
tions submitted via the host are processed by the host 
until the request is reduced to a call for a single row 
of a single table. At that level, the request can be 
handled by the resident DBMS. If the table-row request 
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includes a boolean, the boolean evaluation is done by 
the host on the data after it has reached the host 
buffer. The table-row routines are: 

Table-Row First , Table-Row Last. The first (last) row of 
a table of the resident database is read into a buffer of 
the host DBMS. Any boolean evaluation is done in the host 
buffer. 

Table-Row Next, Table-Row Previous. The next (previous) 
row of a table of the resident database is read into a 
buffer of the host. Any boolean evaluation is done in the 
host buffer. 

Table— Row Insert, Table— Row Delete , Table— Row Update . A 
row of data of a table in the resident database is 
inserted, deleted or updated. 

Table-Row Connect. A row of data which has just been 
inserted into a table in the resident database, is con- 
nected to the proper parent. This routine only has 
applicability in a database of network structure. 

Table-Row Disconnect. A row of data is disconnected from 
the designated parent, and if that is the last parent, 
the row is deleted from the database. This routine only 
has applicability in a database of network structure. 

Table-Row Parent. Given a row of a table, and the name 
of a parent table of that table, this routine returns a 
row of data from the parent table. This routine only has 
applicability in a database of network structure. 

Assigning and Deassigning Resident Databases. Before 
either table-row routines or path routines can access a 
resident database, certain initialization functions must 
be performed. Similarly, after path or table-row access 
routines to a resident have been performed, some termina- 
tion operations functions must take place before the res- 
ident DBMS is exited. These routines are as follows: 

Assign Database. This routine performs "housekeeping" 
functions necessary to allow the resident to communicate 
with the host: it establishes the necessary data buffers 
and variables needed by the resident, logs on to the 
resident, provides the necessary security, performs any 
necessary language translation or execution of query lan- 
guage statements . 
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Deassign Database. This routine performs "housekeeping” 
functions necessary to terminate host interaction with a 
resident: closes the resident database, logs off of the 
resident DBMS, and deallocates any special data areas set 
aside by Assign Database. 

Interface templates 

The next section discusses the set of templates that 
makes up each of our interfaces. 

What are they? 

The templates are the "building blocks" of each resi- 
dent interface package. There is one template for each 
interface component (described above) in every resident 
DBMS interface. The construction of these templates is 
the primary task of you, the interface builder. Once 
the templates have been constructed and installed, 
software in the DAVID system works with them to form 
the complete interface. 

The templates can contain 

- high-level programming language statements 

- calls to DAVID data management routines 

- calls to your own DBMS data management 

routines 

Some templates contain a mixture of the three types of 
statements ; some contain only one or two of the above, 
depending on your DBMSs requirements, and on the pur- 
pose of the routine. A sample template, that for a 
selection-projection (retrieval) routine for the ORACLE 
(a relational) DBMS, is shown below, just to give you a 
sense of what templates look like. No need to study 
it; we'll examine more templates in detail later in 
these guidelines. 

How are the templates constructed? 

You (the interface builder) construct a set of tem- 
plates for any DBMS you want to use. This set of 
templates is used by all databases on that DBMS and for 
all gueries and transactions issued under that DBMS. 

So if all of your databases run under the same DBMS, no 
matter how many databases you want to hook into the 
DAVID system, you need only build one set of interface 
templates. If you use several different DBMSs for your 
databases, say, three different DBMSs, then you will 
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need three different sets of templates for your three 
interfaces. Detailed instructions as to how to con- 
struct the templates (and what to do with them when 
you're finished) appear below. 

Where do they fit into the DAVID system, and how do 
they interact with DAVID? 

For this illustration, let's assume that you want to 
issue a selection-projection query on your employee 
database , such as 

SELECT name, ss# FROM employee WHERE sal- 
ary > 50000 

— that is. Give me all names and ss#s of people in the 
database who have a salary greater than 50000. Let's 
also assume that your database runs on the ORACLE DBMS. 
Briefly, here's what happens when that query is entered 
into the DAVID system: As soon as DAVID determines 

that the query is intended for an ORACLE database, the 
ORACLE interface is "activated", that is, the template 
corresponding to the particular ORACLE transaction (in 
this case, selection-projection) is retrieved from the 
template "cluster". The associated software fills in 
the template with database-specific and query-specific 
information and, in most cases, writes it to a file. 

The result is a program containing a mixture of state- 
ments, commands to ORACLE and commands to DAVID. When 
this program is executed, your query is performed. 

Some interface commands behave differently; for exam- 
ple, for "micro" DBMSs such as DBASE there is no 
programming language support, so the file built by the 
interface software simply captures your query results 
onto a file, which can then be read by DAVID. Some 
DBMSs don't have query language support. In these 
cases, retrieval routines must be built into DAVID in a 
different way. That's why, before building an inter- 
face, it's important to determine what type of DBMS 
you are using. The type classifications are explained 
below. 


Contract NAS5 30304 - Final Report 


Page 38 




Report Body 


How to Build an Interface 

In this section, we present detailed instructions for cre- 
ating interface templates. If you read and follow the 
instructions carefully, hopefully you will be able to build 
an interface to DAVID for your DBMS. 

Determining the interface type for your DBMS 

The first thing you must do is determine into which type 
classification your DBMS falls, for DAVID'S purposes. 
Depending on the DBMS type, some of the interface tem- 
plates differ. Here is a description of the types: 

Type 1 DBMSs have the following characteristics : 

— they support databases which are composed 
of tables of data with no physical connections, 
i.e., no parents, children, or sibling point- 
ers. These are commonly called relational 
databases. 

— they support a query language 

— they support an interface to a high-level 
programming language, such as C or FORTRAN. 

Type 2 DBMSs have the following characteristics : 

— Their databases consist of tables (or records) con- 
nected, via pointers or physical proximity, to children, 
and to a single parent. There may also be sibling 
connections. A table can have multiple children, but 
only a single parent. These are commonly called hierar- 
chical databases. 

— Their databases can be accessed via path routines, 
i.e., "macro" routines for the DBMS which, when given a 
path through the database consisting of parents, chil- 
dren, the children of those children, etc., will access 
the tables which make up that path. 

— They support an interface to a high-level programming 
language, such as C or COBOL. 

— Some support a query language, some do not. 

Type 3. DBMSs have the following characteristics : 
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— their databases consist of tables connected, via 
pointers, to children and parents. There may also be 
sibling pointers. A table can have multiple children, 
and multiple parents. These are commonly called network 
databases. 

— access of Type 3 database is via table-row routines, 
i.e., "macro” routines for the DBMS which, when given the 
name of a table and of the proper parent for that table, 
read/write/update/delete the table (or the parent) in 
that table-parent set 

— they support an interface to a high-level programming 
language, such as C or COBOL 

— most of them do not support a query language 
Type 4 DBMSs have the following characteristics : 

— they support databases structurally composed of tab- 
les of data with no physical connections, i.e., no par- 
ents, children, or sibling pointers. These are commonly 
called relational databases. 

— they do not support an interface to a commonly-used 
high-level programming language, such as C or FORTRAN. 
Some support a limited language, with a very restricted 
set of operations, but they are not stand-alone lan- 
guages, i.e., they are a part of their particular DBMS 
environment, and run only under that DBMS. 

— they have some sort of query capability; usually it is 
a primitive version of a query language. 

These DBMSs commonly run on microcomputers. 

Type 5 DBMSs have the following characteristics : 

Type 5 DBMSs are not, strictly speaking, database manage- 
ment systems. The "databases" which will require a TYPE 5 
interface consist of data stored on tape or other media 
as ASCII or EBCDIC files. Some of these files are part 
of a "system", i.e., they are described by headers of a 
standard format which contain parameters to aid in the 
interpretation of the data. Others have no header infor- 
mation, and it is up to the user to supply all routines 
to manipulate the data. In our research, we have treated 
all such files as another type of DBMS, with the missing 
database processing capabilities provided by the host. 

We will refer to them as "generic files". 
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An interface to generic files has proven to be an 
extremely useful tool. A great deal of data at NASA is 
on such files, and conversations with scientists at NASA 
has shown that the ability to operate on files with the 
power of a heterogeneous DBMS would be most welcome. 

Residents classified as Type 5 exhibit the following 
properties: 


~7 ^heir structure consists of a single file con- 
taining identically formatted records 

— — they can be processed by any high-level program- 
ming language that has I/O consonant with their file 
organization 

they do not support a query language 

software used to process their data is user- 
supplied? i.e., they have no associated data- 
manipulation routines as do DBMSs 


Using the information supplied above, you should be 
able to determine what type of DBMS your is. Here's 
a review of the points above: 

— if it has a query language, it's Type 1 

— if it has no query language, but a host 
language interface, and it's hierarchically struc- 
tured, it's Type 2 

— if it's the same as Type 2 but has all the 
network features, it's type 3. 

— if it's a micro DBMS, with some limited 
query facility and no commercial language interface, 
it's Type 4 

— if it's not a DBMS at all, but just a 
collection of files, it's type 5. 

The Generic Templates: Filling in the @@ signs 

We have designed generic templates for you to work with 
in building your specific interface templates. For each 
DBMS type (types 1 through 5 are described above) , 
there's a set of generic templates, one for each module 
of your interface. As soon as you have determined which 
type of DBMS you are working with (see the type descrip- 
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tions above) , your job will be to fill in the generic 
symbols — they are "00" (double "at" signs) — with 
information specific to your DBMS. 

Building the Definition Generator Templates 

There is a single generic definition generator template 
for all database types described. See figure 8 for the 
complete template. Some of the types use only a subset 
of the keywords in the generalized template; others use a 
different subset. Keywords which are not used are simply 
deleted, as we'll see in our example below. 

In this section, we'll work through an example, building 
a template for definition generation. Then we'll outline 
a general strategy for filling in a Definition Generator 
template. Next, we'll discuss other considerations 
introduced by the different DBMS types. 

An Example 

The object of our efforts in this example is to produce 
a Definition Generator template for ORACLE from a real 
sample ORACLE database definition, using as a model the 
generic Definition Generator template. 

Figure 8 is the generic template for the Definition 
Generator for a type 1 DBMS. We'll fill it in step by 
step for the ORACLE DBMS. You may wish to have figure 
8 in front of you, as well as figure 9, a sample ORACLE 
database definition. 

The ORACLE database definition in figure 9 is, along 
with every other database definition, made up of two 
types of objects: ORACLE components (keywords and sym- 
bols, such as the words "create table" and "char" and 
"INT", and the symbols "(" and ")" in our example); and 
non-ORACLE components, such as the variables "student" 
and "name" and the length "8". In our generalized 
template, the ORACLE components correspond to the "00" 
items; the non-ORACLE items, to the "0" items in the 
template. To build an ORACLE template from a general- 
ized template, we replace the symbols beginning with 
"00" by the ORACLE keywords. Thus, the completed ORACLE 
template will contain only two kinds of items: ORACLE 

components, and template symbols beginning with "0". 
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Note that we do NOT replace the symbols beginning with 
"®" by non-ORACLE items; if we did that, the result 
would be, not a template, but a specific ORACLE data- 
base definition. By leaving the symbols, we create 
a template into which a variety of variables can be 
filled in during definition processing. 

We begin by scanning the template, line by line, com- 
paring it with our ORACLE example. For every line, if 
there is an ORACLE keyword corresponding to the 
template "00" symbol, we replace the template "00" sym- 
bol with that ORACLE keyword. If there is no corre- 
sponding ORACLE symbol, we eliminate the template " 00 " 
symbol. If there is an ORACLE constant (variable 
name, etc.) corresponding to the "0" (constant) sym- 
bol, we leave the template symbol alone; if there is no 
corresponding ORACLE constant, we eliminate the 
template "0" symbol. 

The first line we encounter is one for schema name 
information. ORACLE has no schema name information, so 
we eliminate the entire line from the template. Simi- 
larly, we eliminate the line for file name, area name, 
and dbname (ORACLE has no database name; only the 
tables of ORACLE have names) . 

On the first line of our ORACLE example, we see the 
words "create table student". We know that "student" 
is the table name; in our template, it appears as the 
symbol 0tablename. The words "create table", then, are 
our 0§tablename keyword. So in the generalized tem- 
plate, we replace "§§tablename keyword with "create 
table". Since this is the only attribute describing a 
table, "00table attribute separator" is eliminated. 
Similarly, the next four lines: parent information 
(ORACLE has no parents) , length keyword, start posi- 
tion keyword, and comment keyword, can all be elimi- 
nated . 

So the first symbol in our ORACLE template is the 
template keyword §beginrtable. Comparing the ORACLE 
template to the generalized template, we see that in 
the case of ORACLE, the information contained in the 
first six lines of the generalized template are not 
needed by ORACLE, and so can be eliminated. 
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Let's look at what we've done so far. We've scanned 
the generalized Definition Generator template, the 
first 12 lines. This much of the generalized template 
is represented in the corresponding ORACLE template as 

CREATE TABLE §tablename 

Before we begin our first ORACLE field (See figure 3.2) 
there is a M (" ; since it appears only before the first 
field, and the corresponding " )" after the last one, 
we conclude that these are table delimiters, not field 
delimiters. So the next line in the generalized tem- 
plate, "©©table left delim" is replaced by "(" i n the 
ORACLE version. Later, we will see that "©©table right 
delim", towards the end of the template, will be 
replaced by which are the symbols that appear at 

the end of each ORACLE table. 

Our first ORACLE field is preceded by nothing after the 
"(", which we have already tagged as a table left 
delim. So we can eliminate the generalized template 
symbols "©©field header" and "©©field left delim" for 
our ORACLE template. Similarly, there is no "©©field 
name keyword". The symbol "©fieldname" represents the 
symbols "name" "id" and "grade" in our sample ORACLE 
database definition. The symbol "©datatype" represents 
the symbols "char" and "INT" in our sample ORACLE defi- 
nition; there are no "©©datatype keyword" parameters or 
"©©field attributed separators". The "©©field length 
left delimiter" becomes "("; the "©©field length right 
delimiter" becomes ")". 

There is no "©©fldstart" information; hence that line 
of the generalized template is not used. Neither is 
there a "©©field comment" section; hence, that line 
can be eliminated. 

The "©©table right delimiter" symbol was discussed 
above; as we see from our sample ORACLE database defi- 
nition, it turns out to be ");". 

The rest of the generalized template symbols fall under 
the category of "network header" information; they are 
used only for Type 3 DBMSs, and so will be discussed in 
that context. We eliminate them for ORACLE 

There is no "@@db right delim" symbol or "©db termina- 
tor" symbol; these items can be eliminated. 

Figure 10 shows the completed ORACLE template. 
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Now we must fill in the data type table information 
(see Appendix for data conversion table) ; then our tem- 
plate package is finished. To do that, we consult an 
ORACLE user's manual and a DAVID user's manual, to 

match up the data types. We come up with the follow- 
ing: 


ORACLE DATA TYPE 

TEMPLATE TYPE # 

DAVID DATA TYPE 

char 

2 

char 

INT 

2 

num 

INT 

4 

float 


A final table to be completed is called the Length 
Parameter table. For all datatypes in your DBMS, 
following questions are answered: 


the 


is there a length field? 

if so, how many length parameters are there? 
if there are two parameters, what do they mean? 


The complete table is in Appendix 4 . 

*r h< f completed template, and the tables above 
tilled in, the interface for your DBMS is now complete. 
Section 3 explains what to do next. 


General Strategy 

5^ h ®<.? revious section / we filled in the generalized 
Definition Generator template using our ORACLE example 
as a model, creating an ORACLE Definition Generator 
template. Here, we outline a general strategy for 
tilling in a Definition Generator template. 

nSwo f /f St thing y° u must do is determine which type of 
DBMS (types l through 5 are described above) . Then 

^ ip . t °. tl ? e . section in this document which describes 
ne Definition Generator Templates for your type of 
DBMS • 2 * 


Type l Definition Generator Templates 

In the example of ORACLE we filled in a type 1 Defini- 

noA^r^ en f^ tor tem P late - Our type l sample DBMS, 

nSL COntain such fields as database name. 
Your type 1 DBMS may require more of these items. 
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To fill in the template, employ the same method as we 
did in our example above: use the generalized template 
as a guideline, and for each symbol prefixed by 

— if that construct exists in your DBMS, 
replace the §0 symbol by the one in your DBMS 

if that construct doesn't exist in your DBMS, 

remove the @@ symbol. 

Type 2 Definition Generator Templates 

Type 2 database management systems support tree- 
structured databases, where the tables can have parents 
and children. So in addition to the information about 
individual fields such as that supplied in the Type 1 
templates, parent and child information must be 
supplied in the definition of a table. 

Figure 3.3 contains the general template for a type 2 
DBMS; figure 3.4 contains a typical type 2 schema: one 
for the IMS DBMS. The following additional keywords 
appear : 

@ @par ent_keywd — to indicate that this is a parent 

tab @!table_length_keywd — to indicate the length of 

the table , ^ . . . 

@@table startpos — to indicate the starting 

position of the table 

@@table_comment_keywd — to indicate a comment 

Associated with the above keywords, there are left and 
right delimiters and separators that must be supplied 
in the proper places. See the example above, in which 
these delimiters are filled in, to see how the process 
is done. 

As an example, the generalized template portion which 
pertains to tables and their hierarchical relationships 
appears as follows (this is a portion of the general- 
ized template) : 

@ @ t ab 1 e_name_keywd @§tbname_prefix @TABLE_NAME @§tbna- 

0BEGINPAR @@table_attr_Sep @§parent_keywd §PARENT_NAME 
0ENDPAR 

0BEGINTLEN @@table_attr_sep & 

@ 6 tabl e_l ength_keywd @ TABLE_LENGTH §ENDTLEN 
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0BEGINTPOS 00table_attribute_sep & 

@ 0 tab 1 e_st ar t_pos_keywd 0 TABLE START POS 0ENDTPOS 
0BEGINTCOM 00table_attr_sep & 

00table_comment_keywd §TABLE_COMMENT 0ENDTCOM & 

When the 00 infonnation on the template is filled in by 
the interface builder with information germane to a 
type 2 database, the resulting text is a piece of the 
template for a database definition of that type 2 data- 
base. Here is an example (this example is a part of 
the database definition for an IMS schema) : 

0BEGINTABLE<\n> 

SEGM NAME=0TABLENAME , PARENT= 0 PARENT_NAME , 

BYTES=0TAB LE_LENGTH , START=0TABLE_START_POS 

so, we can see, for this example, 

00table_name_keywd is "SEGM NAME=" 

® @table_attr sep (separators between table attrib- 

utes) is 

there are no comments, so 00table_comment_keywd is 
eliminated, along with 0BEGINTCOM, 0TABLE COMMENT 
and 0ENDTCOM ~ 

Proceeding along these lines, and using the techniques 
illustrated m the ORACLE example, above, we either 
fill m the rest of the 00 symbols with their DBMS- 
dependent counterparts, or delete them. 

Below is an example of a piece of a type 2 database 
definition, the result of the interface driver's opera- 
tion on the template subset shown above: 

SEGM NAME=employee, PARENT=deptment , BYTES=24 

This is an actual portion of the database-specific com- 
mand that would get executed by the resident database 
system to create a new database. The rest of the 
template, and hence the code generated to define the 
new database, is the same as for Type 1 databases, and 
so will not be discussed here. 

Type 3 Definition Generator Templates 

Type 3 definition generator templates differ from those 
of Type 2 only in that the data organization of the 
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databases is different. Since Type 3 databases are 
network in structure, one child can have several par- 
ents, and so the structure described above will not 
suffice. Instead, the generalized template contains 
information about SETS, which is what child-parent 
tuples are usually called. For each set, the requisite 
information to be supplied is the name of the parent, 
or OWNER, as it's often called, and the name of the 
child, or MEMBER, as it is sometimes known, plus appro- 
priate delimiters. 

Here is an example of a subset of the generalized 
template used to connote these relationships. The rest 
of the template is the same as for Type 1 DBMSs. 

§§network_header 

§BEGINSET<§§set_sep><@@set_left_delim>& 

< 0 § set_r ight_del im> 

@@set_name_keyword §SET_OWNER_NAME §@set_name_sep 
0SET_MEMBER_NAME & 

@@set attribute_left_delim 

@@set owner keyword §SET_OWNER_NAME @@set_attnbute_se 
parator & 

00set_member_keyword @SET_MEMBER_NAME & 
§§set_attribute_right_delim & 

0ENDSET 

We now fill the above template subset in for a sample 
Type 3 DBMS; namely, IDMS. We have no @@net- 
work header, so we eliminate the line. Our set_na- 
me_keyword is SET NAME IS; our set_owner_keyword is 
OWNER IS; our set_member_keyword is MEMBER IS. The 
completed template subset for this DBMS, then, is: 

0BEGINSET 

SET NAME IS 0 S ETMEMBERN AME - 0 SETOWNERNAME \n 
OWNER IS 0 SETOWNERNAME \n 
MEMBER IS 0SETMEMBERNAME \n 
0ENDSET \n 

to be repeated for as many sets as there are in the 
specific database. A completed example of this subset 
of a database definition, completed for a department- 
employee database, is as follows: 

SET NAME IS deptment-employee 
OWNER IS deptment 
MEMBER IS employee 
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The rest of the database description is generated as it 
is in the other database types described above. 

Type 4 Definition Generator Templates 

The database definitions for Type 4 databases do not 

ln structure of those of type 1. Since these 
databases are tabular in structure (in fact, they are 
usually limited to a single table), and since the tab- 
les are never connected, they have no parent or set 
pointers, and so the subset of the generalized template 
used in type l databases also applies to them. 

I°^. a . c ? m P lete explanation of how to fill in a type 4 
definition generator template, see the ORACLE example 

to? V t4mplates 6 explanation of fc yP e 1 definition genera- 

Type 5 Definition Generator Templates 

There are no Definition Generator Templates for obiects 
of Type 5. Since these are not databases, but rather 
general files, there is no "schema" or database defini- 
bS Senerated here. Type 5 databases rely only 

d r E ar ^' * he DAVID database definition, to 
nJS™ b them. To define a Type 5 database to the 
DAVID system, you simply use the DAVID DEFINE command 
W€ ff a DAVID database (see the DAVID user's 

S?ORF 0f the DEFINE command); in the 

clause at the end of the DEFINE, you fill in 
the DEMS type as FILE and the name as the name of your 
flle ’ Eor ex ample, to create a definition for a file 
named FI LEI , your DAVID DEFINE command ends with the 
clause 

STORE AS FILE (FILE1) 

™^ tb V eC 4° n Testin< ? You r Interface Components , for 
tion lnformatlon on how to generate a database defini- 


Building the Define Templates 

tor r Tem^i'^o T ? lnPlate f? er 9 es from the Definition Genera- 
n ? Pl m (s f e sectlon 2.3, above) you constructed. 
3^>i ^ lnS Temp i ate surrounds the Definition Generator 
drmS JnH conuna *? ds . needed to bring up, or activate, your 
MS and provide it with the necessary security, and the 
commands needed to exit from your DBMS. Usually, this is 
only a command or two. y ' nis ls 
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The commands for the DEFINE appear in the Definition Gen- 
erator template, at the top and the bottom. 
have completed the process of filling in (or deleting) 
the -prefixed symbols in the generalized template, 

these commands will be filled in also; there is nothing 
additional for you to do. 

Building the install Templates 

The Install templates are constructed in the exact same 
manner as the Definition Generator templates; remember, 
the only difference between the Define operations andthe 
install operations is that the Define creates an entirely 
new database from scratch, while the Install connects an 
existing database to the DAVID system. 

Building the Drop and Delete Templates 

The Drop operation is entirely a DAVID matter, since the 
Drop operation simply disconnects your database from the 
DAVID system. No resident database commands are needed 
for a Drop, and so there is no template to construct. 

The Delete operation, on the other hand, both drops the 
database definition from the DAVID system and deletes the 
database itself. So the template for this operation con 
tains the command to actually delete, or erase, the data 
base definition and all its associated data from your 
DBMS. The template is a simple one; Dust replace the 
0 @delete_database symbol with the language your DBMS uses 
to delete a database. 

Building the database access templates 

There are several different methods for building the 
database access templates, depending on the database Type 
of your DBMS. For those DBMSs which support a query 
language, (i.e.. Type 1 and type 4 DBMSs), the purpose of 
the template is to tell the DAVID system how to interpret 
the query. For those DBMSs which have no query languages 
and which have interfaces at the table-row level (i.e., 
Types 2, 3 and 5), the template helps to construct rou- 
tines to walk through your DBMS and feed information to 
DAVID, or insert information from DAVID. 
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The access templates for Types 1 and 4 DBMSs, i.e., those 
which serve as aids for query translation, reside as data 
in the host DBMS, and are activated as an aid to building 
specific queries at execution time. The access templates 
for the other DBMS types serve a completely different 
function: they are aids to interface builders for writing 
procedures that will then be linked into the host system. 

So filling in the generalized access templates for Type 1 
and Type 4 DBMSs yields another set of templates, con- 
taining symbols prefixed by to be filled in at 

execution time with query-dependent information; while 
the access templates for the other types of DBMS are 

in with actual code that gets compiled and linked 
into the host system. There are no symbols in these 
completed templates; there is only executable code. 

NOTE: Writing the code for Type 2, 3 and 5 interfaces 
sometimes presents a "language" problem. For example, we 
wrote an interfaces to IDMS in C, since the code was 
embedded inside a large system which was all written in 
C; IDMS has a protocol with COBOL, PL/I and IBM Assem- 
k-j- er but not C. So the register conventions are all 
different, parameters are passed differently, and many 
potential problems can result. Let the coder beware! 

In either case, the filled— in database access templates 
form the heart of the interface; they provide the mecha- 
nism for accessing the data. 

Type 1 Database Access Templates 

Below is the generalized template for database access 
for Type 1 DBMSs. It will also be used for Type 4 
DBMSs, as we will see below. As we did with the 
Definition Generator templates, filling in the symbols 
beginning with "@@" for our DBMS will yield a DBMS- 
specific template to be used for queries. We will 
proceed below, with an example. 

There are also two tables which accompany these tem- 
plates: the Linguistic Convention Table (LCT) and the 
Boolean operator Table (BOT) . These must be filled in 
yith information which tells the host system how to 
interpret your query, after filling in the templates, 
completing the LCT and the BOT will provide a complete 
interface. 
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©©invoke_DBMS 

©©give_password ©RUID @@pwd_sep ©@give_userid ©RPWD 
© © open_db © dbname 

©©establish_file_device ©FILENAME 

@©select_command 

©BEGINSELECT 

©result_f ield_sepx@©result_field_lft_delim>& 

<© ©resul t_f ield_rt_del im> 

©RESULTFLD 

/* this may also contain table prefix, 
see table 1 for list of options */ 

©ENDSELECT 

© © f rom_command 
©BEGINSOURCE 

/♦note: doing this as a loop allows for JOINS */ 

< © © source_db_sep>< © © source_db_l f t_del im> & 

< © © sour ce_db_rt_de 1 im> 

©SOURCEDB 

/* this may contain db name and/or table name */ 
/* and will appear as ©©SOURCEDB or ©©SOURCETABLE 

*/ 

©ENDSOURCE 

©©bool_command 

©©boollftdelim ©bool_string @©bool_rt_delim 


prefix. 


/* ©©bool_string may also contain table 
see BOT for list of options */ 


©©close_db 

©©exit 

©©terminator 

When the ©© symbols have been filled in with keywords 
from our DBMS language (or NULLed out, if that language 
construct doesn't exist in our DBMS) , the result will 
be a query-dependent template to be filled in at run 
time. 


Let us fill in the template for the ORACLE DBMS, fol- 
lowing through from the database definition example. 
ORACLE has an on-line query language, OLQ, through 
which our query will be generated. Below is an example 
of an ORACLE query, to retrieve information from a 
student record file. 
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OLQ 

USER = marsha, PWD = hi 
OPEN students 

SELECT name, id, grade FROM students 

WHERE semester = 'fall' AND year = 1989 AND course 
= 'cscl26' 

OUTPUT TO filel 

EXIT 

In the above template, 

00open_DBMS is replaced by OLQ 
00user_id is USER = 

00pwd_sep is , 

00pwd is PWD = 

00open_db becomes OPEN 
00establish_f ile_device is eliminated 

Continuing in this vein, using our example and the 
generalized template, we come up with the following 
template for ORACLE. Notice that it contains only 
items with a single ; those are query-dependent and 
get filled in at run-time. All the symbols 
beginning with "00" have either been replaced by DBMS- 
specific constructs, or have been eliminated. 

ORACLE QUERY TEMPLATE 


OLQ 

OPEN 

0BEGINSELECT 

< , ><><> 

0RESULTFLD 

0ENDSELECT 

FROM 

0BEGINSOURCE /*note: doing this as a loop allows for 
JOINS */ 

<,><><> 

0SOURCEDB 

0ENDSOURCE 

WHERE 

0bool_string 0BEGINRESULT 
OUTPUT TO 0RESULTFILE 
CLOSE 0dbname 
EXIT 


Contract MAS5 30304 - Final Report 


Page 53 



Report Body 


Now we need to fill in the two accompanying tables; 
then we are finished. First, the I£T. 

The Linguistic Convention Table provides a "picture” of 
the query for it to be properly interpreted by the 
system: such items as 

— whether spaces are required around operators 

- whether field names have to be qualified by tables 

The format of the table is just a set of answers to 
simple questions; the complete table appears in the 
appendix to this document. 

The Boolean Operator table aids the system in con- 
structing a Boolean condition for your query in your 
DBMS. For each Boolean operator that the host has, you 
are requested to represent it in the language of your 
DBMS. Also, the precedence rules are established. 

This table also appears in the appendix to this docu- 
ment. 

These tables, along with the completed template, form a 
complete picture of your DBMS; the interface software 
of the host DBMS system can now construct queries in 
your query language to be submitted on your databases . 

Type 2 Database Access Templates 

Type 2 and Type 3 DBMSs are both connected to the DAVID 
system via inner interfaces. In that case, as you may 
recall, we need to provide five database operations for 
the interface, namely, open , close, first, next, and 
insert. Since database systems differ greatly in the 
way these operations are handled, a detailed case of 
both a Type 2 and a Type 3 interface will be discussed 
below. 

If there were a database access template for type 2 and 
type 3 DBMSs, it would simply consist of the commands: 

@@open_database 
@@read_first_record 
§@read_next_record 
@@close database 
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These commands would be used quite differently than the 
conventional template commands. Each would yield not a 
string of text, but a function or collection of func- 
tions, written in C or some other high-level language. 
The functions themselves would not appear sequentially, 
but would be imbedded in other functions, scattered 
throughout the DAVID DBMS code. They would be compiled 
and linked into DAVID, and executed via DAVID function 
calls. Their net effect would be to make the resident 
database function, not like a resident database with 
its own associated DBMS, but like a DAVID database. 
DAVID would call on the resident DBMS only to implement 
the calls named above. 

Below we described the 4 template commands described 
above, plus a fifth one: open , first , next , close , and 
insert. 

The open command must "bring up" the DBMS, open the 
specific database to be processed, and perform some 
"housekeeping chores". Some of these might be (the 
actual tasks to be done depend on the requirements of 
the particular DBMS to be interfaced) : allocate a work 
area; allocate a file control block for the database 
and initialize it; set up an error reporting mechanism; 
open any files associated with the database. 

The close command must close the database, perform any 
DBMS-specific functions required, such as freeing any 
storage areas allocated by the open routine, and exit 
from the DBMS. 

Type 2 databases generally are hierarchal in nature, so 
that when we are asking for the first record or the 
next record, we must set those requests in the context 
of the parents of the record. Since we are supplying 
the parent (which the host DBMS keeps track of) for 
each call, these calls are in actuality for the first 
or next record within a particular parent. 

Since first and next routines are usually implemented 
via subroutine calls in Type 2 databases, the two oper- 
ations differ from each other only in that they are 
different parameters to the same subroutine call, or 
different subroutines. For example, in the FOCUS DBMS, 
the call to retrieve the next record within the same 
parent is a call to routine focnxp; the call to 
retrieve the first record is a call to routine focfst. 
All parameters are the same. 
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Similarly, insert is implemented by a similar subrou- 
tine call, requesting that the record be inserted into 
the proper place in the database. 

Type 3 Database Access Templates 

As in Type 2 interfaces, these DBMSs are connected to 
the host via inner interfaces. An explanation of the 
open , close , first , next , and insert follows below. 

In the open command, the DBMS is invoked, usually via 
system commands, and the database is opened. Also, some 
of the following "housekeeping" functions are per- 
formed: storage is allocated for schemas and subsche- 

mas ("bindings" are created), data control areas are 
set up, an error-checking mechanism is established. 
Note: in type 3 DBMSs, often a new declaration for the 
subschema control area must be set up for every differ- 
ent kind of database operation to be performed on that 
schema; in particular, get (first or next) and insert 
must have different subschema control areas. The easi- 
est way to handle this is to automatically set up two 
— one for reading, one for updating — in every open. 

The close operation closes the database, deallocates 
any storage allocated by the open operation, and exits 
from the DBMS. 

The first , next , and insert operations are usually all 
done via a single procedure call. The procedure has 
parameters for the subschema name, the name . of the 
record, the name of the physical area in which the 
record sits, the control area in which currency is 
maintained so the request for a "next" record has some 
meaning, and, of course, the database operation. In 
IDMS, for example, the single subroutine is called 
IDMS ; a call to obtain the next record would be 

CALL IDMS (SUBSCHEMA_CTL, IDBMSCOM(ll) , 

RECNAME , AREANAME, ERROR) 

where the IDBMSCOM number signifies the database opera- 
tion. 

Type 4 Database Access Templates 

Type 4 DBMSs have a language that resembles a query 
language, although in some cases it is rather primi- 
tive. As a result, they use the same kind of template 
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as is used for Type 1 DBMSs: the query template. The 
process used to fill in the query template is described 
in detail in section on type 1 database access tem- 
plates, and an example appears there. 

Type 5 Database Access Templates 

Type 5 databases are not, strictly speaking, databases 
at all. They have no query languages associated with 
them, and so the only approach to take is the inner 
interface approach. A brief discussion of open, close , 
first, next and insert follows. We will show that the 
only operations to be constructed by the interface 
builder for processing Type 5 databases are first, 
next , and insert. 

The open routine simply opens the file upon which the 
data is residing. At execution, the name of the file is 
passed to the routine as a parameter. Any work data 
areas to be set up or error-reporting mechanisms to be 
established, are already built into the DAVID system 
for our generic file interface. So there is nothing 
for the template builder to do here. 

The same is true for the close operation: the DAVID 
system already contains a generic file routine for 
closing the data file and deallocating any storage 
areas for that processing. So nothing needs to be 
done. 

The entire template for accessing a database, then 
would consist of the commands: 


0 0read_f irst_record 
00read_next_record 
00 insert record 


The first and next operations differ only in that the 
first routine must read past any header on the front of 
the file. So the template routines to be filled in for 
the first routine are: 


and 


§ 0 read_past_header 
00 read next record 
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Routine read past header simply bypasses any heading 
information on the front of the file, and positions us 
for the next read at the first piece of data on the 
file. This routine will be the same for every file on 
the same file system (our FITS interface, for example, 
contains a routine to read past any FITS header) . If 
the file has no header, this routine will be null. 

The object of the read_next_record routine is to place 
the data from one record of the file into a host data 
buffer. Once the data is in this buffer, the host 
system can then process it . The routine must go 
through the data items one at a time, performing pre- 
processing and data conversion where necessary and 
moving the data into the corresponding position in the 
proper DAVID data buffer. Preprocessing might include 
stripping leading characters or trailing characters 
from the data. Conversion might include translation 
from ASCII to binary data representation. 

The insert operation moves the data from the host data 
buffer into a record of the file; therefore it is the 
opposite of the next operation. The components of the 
insert operation parallel those of next, but the data 
is moved in the other direction. Once one of the 
routines is written, it will be very clear what is 
needed to construct the other. 

What to do with the templates you just constructed 

Depending upon the Type of your DBMS, the database access 
templates you constructed are used in different ways. How- 
ever, the Define, Delete and Install templates are used in 
the same way, regardless of what kind of database system you 
have. We explain their use first. 

The set of templates you just constructed will become part 
of the DAVID system, as a "system cluster" of data which 
DAVID calls upon to do its work. Each time a request for a 
database operation on one of your databases comes to DAVID, 
the proper template — the one for the correct operation on 
your DBMS — must be retrieved and filled in by DAVID. The 
resulting text string contains a set of instructions to your 
DBMS. When that text string is executed, it will "bring up" 
your DBMS and perform the operation on it. 
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For all DBMS types, the DEFINE, DROP, INSTALL and DELETE 
templates are processed as described above. For database 
systems of Types 1 and 4, the database access (query pro- 
cessing) templates are also treated in this manner; however, 
for database systems of types 2, 3, and 5, they are used 
quite differently. Here, we outline that process. 

The database access templates for database systems of types 
2, 3, and 5, you may recall, generate not query-dependent 
templates to be filled in with query— specif ic information, 
but procedures. These procedures are general, i.e., they 
contain no query-specific information, and they have to be 
compiled and linked into the host DBMS — once. So when the 
access routines are finished, they are delivered to the 
DAVID database administrator, who links them into the DAVID 
system, and makes some system changes to accommodate the 
routines. For DBMS Types 2, 3, and 5 you should skip the 
next section, since there will be no templates to install, 
and proceed with the section which discusses the testing of 
your new interface. 

Installation into the Template Cluster 

Each template you have generated should be in a separate 
text file. On the front of the file, 2 pieces of infor- 
mation must be added: the DBMS number, and the type of 

operation. The DBMS number is a distinct 3-digit number 
for each non— DAVID DBMS on the system; ORACLE, for exam- 
ple, is DBMS number 101, while INGRES is DBMS number 102. 
The DAVID database administrator must assign a n umb er to 
the DBMS before the templates can be installed. The type 
operations are as follows (they are 8-character codes) : 

DEFINE 

INSTALL 

DROP 

DELETE 

SELPROJ 

STORE 

Note: the first four operations are for any DBMSs; the 
last two are for Type 1 and Type 4 DBMSs only. 

There is a stand-alone program called load_template_clus- 
ter which asks for the name of the file in which the 
template sits; then reads that file and adds the data to 
the DAVID template cluster. 
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A few things must be done to the DAVID system before you 
can start testing your interface components. These oper- 
ations will be performed by the database administrator of 
DAVID. They are: 

Your DBMS must be assigned a 3-digit DBMS number, which 
is added to the resident database structure numbers [in 
clstruct .h] . It is described above. 

The logical statements which determine which resident 
interface belongs to which query must be expanded to 
include your DBMS name and number . 

Once these actions have been performed, and DAVID has 
been relinked by the database administrator, you are 
ready to begin testing (and using!) your interface. 


Testing your interface components 

You must test your interface components on a "real” data- 
base on your DBMS. To do this, you must first Define or 
Install a database of that type. Let's try Define first; 
you can do it through the DAVID system. You simply issue 
a DAVID DEFINE command; the end of the command says STORE 
AS XX(YYY) ; where XX is the name of the DBMS, and YYY is 
the name of the new database you wish to create. So if, 
for example, you wish to create an ORACLE database called 
DB1 , your DEFINE command would end .... STORE AS ORA- 
CLE (DB1) ; See the DAVID users manual for the syntax of 
the complete DEFINE command. 

You can also create a new database in your DBMS via a 
DAVID query. This way, it immediately gets loaded with 
data, also. Simply query an existing DAVID database and 
specify that the results be stored in a database in your 
DBMS. For example, to create database DB1 as an ORACLE 
database containing the same information as a DAVID data- 
base called DBO , issue this query; 

CREATE ACTUAL CLUSTER nl . usrl . f ilel . dbl 
SELECT * FROM nl . usrl . f ilel .dbO 
WHERE all 

STORE AS ORACLE (DB1) ; 

NB: nl is the physical node on which your data resides 
usrl is your user id 

f ilel is the physical file on which the data resides 
See your DAVID database administrator for help in deter- 
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mining these values. 

database has been created, and is connected to 
on it* SYStein ' you can test the following operations 

Can i SSUe c 5 ueries • (See the DAVID user's manual 
tor the syntax of query commands) . Your queries can 
transfer data from one database to another in your DBMS 
from yours to DAVID, from DAVID to yours, or to and from 
yours and any other DBMS for which a DAVID interface 

vXisls • 

b) You can browse through your database, looking at 
records one at a time, setting "windows" (selected 

lillrVr+ t ?* reStr t Ct t 5 e number of fields and booleans to 
number of records. You can even insert 

thS pf °T> y ° Ur database usin< ? tb is browsing tool. See 
the Reading Room user's manual for how to do this. An 

ia?°£ tant • caveat : y ° u can use this feature only if your 

buiftTt S fM 6 1S a ? inner interface, i.e./it .as 
Zll* the table-row level. DBMS interfaces that have 
query-level interfaces can only support queries; no 
browsing is permitted. 

Summary - The Capabilities of your interface 

to\he a DAVID r svJS aSe ir nagem r t system has been interfaced 
ine DAVID system, all your databases can be accessed 

transferred h^ at ® d it* the DRVID system, and data can be 
tem an^ the DAVID system and your database sys- 

5??' “d between any other DBMS connected to DAVID and your 

DAVID datah Stem ‘ In . short ' your DBMS becomes just another 

jurt mo?e DAV?n°5I? n i Zati0n . ty ? e ' and your databases become 
Dust more DAVID databases of different types. 

For every database you wish to process via the DAVID svstem 

IbouTtLTatll 1 Lt °J DAVID ' i e " you must tell llvll Stem ' 
done H o 2 a ?f baSe f chema * Once the installation has been 

your* command^ 1 SpeCtrum of the DAVID language is at 

r?rqoverild°bv r ?^T S oth I r .than queries on your databases 
^,L- 9 ,_ b Y the type of interface you have to the DAVID 

ystem, which m turn is determined by the TYPE classifica- 
tion you selected for your interface, based on the charac- 

oHyp^YUT have * th The ^-faces^ f o? la?ab ases 

types 3 and 4) have the most flexibility; you can issue 
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queries on them, as well as browse through them using the 
DAVID browsing tool. The outer interfaces are not endowed 
with browsing capability; however, GSQL is a very powerful 
query language, and provides a full range of database access 

capabilities . 
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Outlook for Phase III 

Ken Wanderman & Associates is vigorously pursuing follow-on 
contracts to this project in two areas. The first area is 
using the results described in this report to enable us to act 
as consultants for parties who have data in various DBMSs and 
files, to interface that data to DAVID. In particular, in the 
astrophysics community within NASA there is great interest in 
using the FITS and FILE interfaces to translate data. The 
arrangements we are pursing would be to have our company per— 
form the translations in house. Such translations might poss- 
^•kly involve writing additional interfaces depending on the 
nature of the data. We expect contracts to be signed within 
the next few months. 

A second area we are pursuing is in the direct sale of our 
technology to commercial database management companies who 
would like to have interfaces of their product to others. The 
concept of interface between commercial relational databases 
has come alive within the time span of this project; and, sev- 
eral major companies such as FOCUS and ORACLE are now putting 
emphasis on interfaces between their products and other 
commercial DBMSs. Unfortunately, there are no commercial het— 
erogeous distributed DBMSs, so our concept remains slightly 
ahead of its time. Our plan is to pursue consulting until the 
market catches up. 
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Suggestions for Further Research 

In our strategies to build interfaces we only considered what 
one could call traditional type database systems; i.e., ones 
based on tables. These were the relational, the hierarchal 
and the network type DBMS. At this point, these traditional 
systems make up the overwhelming majority of systems m use by 
scientists and business and industry. However, the market for 
commercial databases is an active one. New products and tech 
nologies are constantly emerging as the demand for more 
sophisticated database products grows. Our approach accounts 
for new products in the traditional area, but DBMS based on 
entirely new techniques may call for interfaces inconsistent 
with our approach. Two types of database systems still in the 
development stage come to mind. One is Hypertext which allows 
a more sophisticated linking mechanism than traditional DBMSs. 
Interface to Hypertext systems should be considered for the 
future, particularly when they become available on machines 
larger than micro computers. A second type of DBMS is the 
object-oriented database. A leading vendor in this area is 
Servio Logic, Inc., whose product. Gemstone, has become the 
pioneering product. While time and resources of this contract 
did not allow us to pursue an interface with Gemstone, our 
company plans to make this effort in the near future. 
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Figure 3 - Typical FITS Header 


SIMPLE 

BITPIX 

NAXIS 

EXTEND 

COMMENT 

COMMENT 

END 


T / File is standard FITS format 
8 / Character information 
0 / No image data array present 
T / There are standard extensions 

AGK3 Astrometric catalog, in FITS Tables Format 
extension header follows in a new block 


XTENSION= 'TABLE 
BITPIX = 

NAXIS 
NAXIS 1 = 

NAXIS2 = 

PCOUNT = 

GCOUNT = 

TFIELDS = 

/ 

EXTNAME 

= 'AKG3 

/ 

TTYPE1 

TBCOL1 

= 'NO 

/ 

TBFORM 

= 'A7 

9 

TTYPE2 

TBCOL2 

= 'MG 

9 

TFORM2 

point 

= 'E4.1 

/ 

TUNIT2 

= 'MAG 

t 

TTYPE3 

TBCOL3 

= 'SP 

9 

TFORM3 

= ' A2 

9 

TNULL3 

— / 

9 

TTYPE4 

TBCOL4 

= 'RAH 

9 

TFORM4 

= '12 

9 

TUNIT4 

= 'HR 

9 

TNULL4 

= '99 

9 


/ Table extension 
8 / 8-bits per "pixel" 

2 / simple 2-D matrix 

74 / no of characters per row 

3 / no of rows 

0 / no "random" parameters 
1/1 group 

16 / 16 fields per row 
/ name of the catalog 

/ the star number 

1 / start in column l 
/ 7 character field 

/ stellar magnitudes 
8 / start in column 8 

/ xx. x standard precision floating 

/ units are magnitudes 

/ spectral type 
13 / start in column 13 
/ 2 character field 
/ blank is indefinite value 

/ right ascension hours 
16 / start in column 16 
/ 2-digit integer 
/ units are hours 
/ null value 
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TTYPE5 = 
TBCOL5 
TFORM5 = 
TUNIT5 = 
TNULL5 = 

TTYPE6 = 
TBCOL6 = 
TFORM6 = 
TUNIT6 = 

TTY PE 7 = 

TBCOL7 = 
TBFORM = 

TTYPE8 = 
TBCOL8 = 
TFORM8 = 
TUNIT8 = 

TTYPE9 = 
TBCOL9 = 
TFORM9 = 
TUNIT9 = 
TNULL9 = 

TTYPE10 = 
TBCOLIO = 
TFORMIO = 
TUNIT10 = 
TNULL10 = 


'RAM ' 

' 12 ' 

'MIN ' 

'99 ' 

'RAS ' 

'E6.3 ' 

'S ' 

'DECDSIGN' 

' A1 ' 

' DECD ' 

'12 ' 

'DEG ' 

' DECM ' 

'12 ' 

' ARCMIN 
'99' 

' DECS ' 

' E5 . 2 ' 

'ARCSEC ' 

'99.99 ' 


/ right ascension minutes 
19 / start in column 19 
/ 2 -digit integer 
/ minutes of time 
/ null value 

/ right ascension seconds 
22 / starting in column 22 

/ xx. xxx standard precision float 
/ seconds of time 

/ declination sign 

29 / start in column 29 
/ character field 

/ declination degrees 

30 / start in column 30 
/ 2 digit integer 

/ degrees 

/ declination minutes 
33 / start in column 33 
/ 2 digit integer 
/ minutes (angle) 

/ null value 

/ declination seconds 
36 / start in column 36 

/ xx. xx standard precision float 
/ seconds (angle) 

/ null value 


TTYPE11 = 'EPOCH 
TBCOL11 = 

TFORMIO = ' E7 . 2 
TUNIT11 = 'YR 


/ epoch of positions 
42 / start in column 42 

/ xxxx.xx standard precision float 
/ units are years 


TTYPE12 = 'N 
TBCOL12 = 
TFORM12 = ' il 


/ no. photo obs. 

50 / start in column 50 
/ one digit integer 


TTYPE13 = 'RAPM ' 

TBCOL13 = 

TFORM13 = ' E4 . 3 ' 

TUNIT13 = 'ARCSEC. YR-1' 
TNULL13 = '9999 ' 


/ proper motion in r . a . 

52 / start in column 52 

/ .xxx standard precision float 
/ units are arc-seconds/yr 
/ NULL VALUE 
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TTYPE14 = 'DECPM 7 / 
TBCOL14 = 57 / 
TFORM14 = 7 E4 . 0 7 / 
TUNIT14 = 7 ARCSEC . YR- 1 7 / 
TSCAL14 = 0.001 / 
TNULL14 = '999 7 / 


proper motion in dec. 

start in column 57 

xxx. standard precision float 

units are arc-seconds/yr 

scale factor = 0.001 

null value 


TTYPE15 = 'DEPOCH ' 
TBC0L15 = 

TF0RM15 = 7 E5.2 ' 

TUNIT15 = 'YR 7 


/ difference in epoch AGK3-AGK2 
62 / start in column 62 

/ xx. xx single precision float 
/ unit is years 


TTYPE16 = 'BD ' 

TBCOL16 = 

TF0RM16 = ' A7 ' 

TNULL16 = ' ' 


/ Bonner Durch. star number 
68 / start in column 68 
/ 7-character field 
/ blanks indicate null 


AUTHOR = 'W. Dieckvoss 7 
REFERENC= 'Hamburg-Bergsdorf 1975 7 
END 
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Figure 4 Assign File 


/************************************************************* 

' * 
* 

* File: 6file_asgn.c 

* Module: scracc 

* Does extra things associated with assigning a general 

* file or FITS cluster (like reading the auxiliary cluster * 

* into the CCA, and opening the file) . * 

************************************************************ 
************************************************************ 

Function: f ile_asgncluster 
File: 6file_asgn.c 

Author: M. Moroh 

Last Update: 8/88 

For general files & FITS, opens files and reads header 
from auxiliary cluster into CCA (new place: res_area) 

Called by routine arbi_asgncluster /scracc/6212 .c 

************************************************************** 


NOTE: This routine is called by the asg. cluster process. It 
does NOT assign the main cluster, which is already done (cl is 
its ptr) . It simply assigns the auxiliary cluster associated with 
it, loads the header infor into main cca, and deassigns the aux 
cl. 

This routine is also called by define cluster (since the define 
operation for file-type clusters also has to assign it) . To avoid 
a big mess, this routine exits if it discovers the header to be 
empty. This means: header isn't constructed yet! So don t try 

to read it! ! ! */ 

# include "chap4std.h" 

/* and utility.h 

JWF - was / marsha.h / in original fits but 
that file has been merged with / chap4sdt.h / 
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#define pmode 0777 /* file access mode for new cluster file 

V 

#def ine VCA_E0T 60002 /* EOF on subcluster read */ 

f ile_asgncluster (vl , cl , c_name , query , access) 

VCA *vl; /* same VCA as usual */ 

CCA *cl; /* CCA ptr for main cluster */ 

char *c_name; /* cluster name of main cluster */ 

char *query; /* if this is to be an "outie", i.e., a fen 

executed */ 

c ^ ar *access; /* whether aux cluster is to be read/write/up— 

date */ 

/* note: the parameter "query" will be null for most general 

files.*/ 

/* only for retrieval systems w. built-in functions will it be 
nonnull */ 

{ 

TCA *tl; /* TCA ptr for table containing data */ 

CCA *c2 ; /* CCA ptr for the auxiliary cluster */ 

SCA *sca ; 
char *uid; 
char *pwd; 

FILE *fopen() , *fp; 

clust_struct *name_ds ; /* cluster name */ 

FF_AREA *file_area; /* pointer to structure for data areas 

*/ 

char *calloc() ; 

char the_name[CLUSTER_HDG_LEN +2]; 
int result = SUCCESS; 
int bind_f lag = FALSE; 

AFIELD *eachfield; /* for allocating fieldinfo */ 

AFIELD *last ; /* to find length of record */ 

char openmode [ 3 ] ; /* mode for opening file (r,w) */ 

int int_length; /* int version of data length. To get 

around */ 

/* USHORT problem (cast it; assign it to 

*/ 

/* eachfield->length) */ 

/* Allocate data areas for file header info, etc. */ 
file_area = ( FF_AREA *) calloc ( 1 , sizeof (FF_AREA) ) ; 

/* Insert a pointer to the resident_areas into the CCA */ 
cl->res_area = file area; 
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/* Set TCA pointer (tl) to first table of CCA (we need it later) 
*/ 

tl = cl->tca_ptr; 

/* Provide the userid and/or password */ 

/* (Is this ever necessary?) */ 

/* uid = (char * ) calloc(l,NAME_LEN) ; */ 

/* pwd = (char * ) calloc(l,NAME_LEN) ; */ 

/* Open up the general file & store its ptr in the CCA */ 

/* Open it for read, write or update, depending on access. */ 

/* On the VAX it would be: */ 

/* JWF - DAVID ops other than delete put a 'D' in the access 
*/ 

/* string - this will have to be resolved eventually but for now 
*/ 

/* checking will be disabled. 

*/ 

/*( 

result = E_ILLEGAL_ACCESS_MODE; 
set_status (vl , E_I LLEGAL_ACCESS_MODE ) ; 

} JWF */ 

/* NOTE: code below will allow for "RW" (though it 7 11 actually 
open "a” */ 

/* in that case) . It won't alllow for "D" */ 

/* Allowing for RW provides multiple user access to same file (I 
think) */ 

eachfield = NULL; 
last = NULL; 
if (result == SUCCESS) 

{ if ( foundit (access, "RW") != NULL) strcpy (openmode, "a+") ; 

else if (strchr (access, 'W') != NULL) strcpy (openmode, "a" ) ; 

else /* cluster is for reading only */ 
strcpy ( openmode , " r " ) ; 

if ((fp = fopen(cl->res_name, openmode) ) == NULL) 

* printf("\n unable to open file %s with access mode 
%c%c\n" , 

cl->res_name , openmode ( 0 ] , openmode [ 1 ] ) ; 
set_status ( vl , E_ARBI_F I LE_CREATE_ERROR) ; 
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result = E_ARBI_FI LE_CREATE_ERROR ; 

) 

} 

/* Now get the header information from the "auxiliary CCA" */ 

if (result == SUCCESS) 

{ 

cl->res_f ile_ptr = fp; 

/* first, allocate a field description structure */ 

eachfield = (struct afield *) calloc(l, sizeof (struct 
afield) ) ; 

eachfield->next = NULL; 

file_area->f irstf ield = eachfield; /* hook structure to cca 

*/ 

/* Now assign and read the secondary cluster for the file, 

*/ 

/* which contains the header information. */ 

/* create the name of the secondary cluster (routine 
get_aux_name ) 

it was created in the define routine (in file 
arbi_hdr.c) */ 

get_aux_name (c_name, the_name) ; 

/* for testing, a single-level table (omit device info) */ 

/* if ((result = 

bindcolumn (vl , c2 , "device" , "device_info" , 

f ile_area->device_info, DCHAR,20 )) 

*/ 

if ((result = asgcluster (vl , &c2 , the_name, "*" , "RWD" ) ) != SUC- 

CESS | | 

(result = 

bindcolumn (vl , c2 , "xheader" , "xname" , eachf ield->name, 
DCHAR , NAME_LEN )) != SUCCESS || 

(result = 

bindcolumn (vl , c2 , "xheader" , "xtype" , eachf ield->type , 
DCHAR, 8)) 

!= SUCCESS | | 

(result = 

bindcolumn (vl , c2 , "xheader" , "xlength" , & (eachf ield->length) , DINT, 
0 )) 

! = SUCCESS | | 

(result = 
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bindcolumn(vl, c2 , "xheader" , "xnodecs" , & (eachf ield->nodecs) , DINT, 
0)) 

I = SUCCESS | | 

(result = 

bindcolumn(vl,c2 , "xheader" , "xcolumn" , & ( eachf ield->column) , DINT, 
0)) 

! = SUCCESS | | 

(result = 

bindcolumn (vl , c2 , •'xheader” , "xcomments" , 

eachfield->comments,DCHAR,200) ) != SUCCESS) 

; /* Don't do anything */ 

> 

/* Read information from header into auxiliary cluster */ 
if (result == SUCCESS) 

{ 

bind_flag = TRUE; 

if ((result = asgsubcluster (vl, c2, &sca, ”*”)) 1= SUCCESS) 

{ 

dasgcluster (vl, &c2) ; 
result = CANT_AS GN_AUXSUBCL ; 

} 

) 

if (result == SUCCESS) 

{ 

scrbfirst(vl,c2, sea, NULL) ? 
if (vl->status == VCA_EOT) 

( /* printf(”\n in file_asgn, xheader cluster showed up 
empty . ” ) ; */ 

/* JWF - Clean up bindings. */ 
if ( (result = 

unbindcolumn (vl , c2 , "xheader” , "xlength" , & ( each- 
f ield->length) ) ) 

! = SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader” , "xname" , eachf ield->name) ) 

! = SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xtype" , eachf ield->type) ) 

! = SUCCESS | | 

(result = 

unbindcolumn (vl, c2 , "xheader" , "xnodecs" , & (each- 
f ield->nodecs) ) ) 

! = SUCCESS | | 

(result = 
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unbindcolumn (vl , c2 , "xheader " , "xcolumn" , & (each- 
f ield->column) ) ) 

!= SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xcomments" , each- 
f ield->comments) ) 

! = SUCCESS) 

; /* dont do anything */ 
dasgcluster (vl, &c2) ; 
return (SUCCESS) ; 

> 

else if (vl->status 1= SUCCESS) 

{ 

printf("\n in file_asgn, cant read 1st header record 
properly") ; 

dasgcluster (vl, &c2) ; 

result = E_CANT_READ_ARBI_HDR; 

} 

} 

/* now unbind all cluster variables; then rebind. */ 

while (result == SUCCESS) 

( 

if ( (result = 

unbindcolumn (vl , c2 , "xheader" , "xlength" , & (each- 
f ield->length) ) ) 

! = SUCCESS | | 

(result = 

unbindcolumn (vl, c2 , "xheader" , "xname" ,eachf ield->name) ) 
! = SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xtype" , eachf ield->type) ) 
! = SUCCESS | | 

(result = 

unbindcolumn (vl, c2 , "xheader" , "xnodecs" , & (each- 
f ield->nodecs) ) ) 

!= SUCCESS | | 

(result = 

unbindcolumn (vl, c2 , "xheader" , "xcolumn" , & (each- 
f ield->column) ) ) 

!= SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xcomments" , each- 
f ield->comments) ) 

!= SUCCESS) 

; /* dont do anything */ 
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else 

{ 

/* set up another memory location for next field info */ 
last = eachfield; /* keep track of last field */ 
eachf ield->next = (AFIELD *) calloc(l,sizeof (AFIELD) ) ; 
eachfield = eachf ield->next; 
eachf ield->next = NULL; 

if ( (result = 

bindcolumn (vl, c2 , "xheader" , "xname M , eachf ield->name, 
DCHAR , NAME_LEN )) 

! = SUCCESS | | 

(result = 

bindcolumn (vl , c2 , "xheader" , "xtype" , eachf ield->type , 
DCHAR, 8)) 

1= SUCCESS | | 

(result = 

bindcolumn (vl,c2 , "xheader" , "xlength" , & (eachf ield->length) , DINT, 

0 )) 

1= SUCCESS | | 

(result = 

bindcolumn (vl, c2 , "xheader" , "xnodecs" , & (eachf ield->nodecs) , DINT, 

0 )) 

1= SUCCESS | | 

(result = 

bindcolumn (vl, c2 , "xheader" , "xcolumn" , & (eachf ield->column) , DINT, 

0 )) 

! = SUCCESS | | 

(result = 

bindcolumn (vl , c2 , "xheader" , "xcomments" , eachf ield->comments , 

DCHAR, 200) ) 

!= SUCCESS) 

; /* Dont do anything */ 
else 

/* now read the next row of the auxiliary cluster */ 
result = scrbnext (vl,c2, sea, NULL) ; 

} 

) /* end of while loop */ 

/* Check for normal ending of while loop */ 
if (vl->status == VCA_E0T) 
result = SUCCESS; 
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/* now unbind all cluster variables */ 
if (result == SUCCESS | | bind_flag) 

( 

if ( (result = 

unbindcolumn (vl , c2 , "xheader" , "xlength" , & (each- 
f ield->length) ) ) 

! = SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader” , "xname" , eachf ield->name) ) 
! = SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xtype" , eachf ield->type) ) 
! = SUCCESS | | 

(result = 

unbindcolumn ( vl, c2 , "xheader" , "xnodecs" , & (each- 
field->nodecs) ) ) 

! = SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xcolumn" , & (each- 
field->column) ) ) 

!= SUCCESS | | 

(result = 

unbindcolumn (vl , c2 , "xheader" , "xcomments" , each- 
field->comments) ) 

!= SUCCESS) 


} 

/* if there's one extra instance of eachf ield. Free it. */ 

if (last 1= NULL) last->next = NULL; 
if (eachf ield != NULL) 

cfree (eachf ield) ; /* JWF */ 


/* Figure out the max record length (not necessary to rd NAXIS 
then) */ 

/* — it's the column of the last record + the length of the last 
rec */ 

/* NOTE: statement below seems to point to FIRST field, not 

last. */ 

/* That's because DAVID stores records BACKWARDS, so first IS 
last. */ 

/* Note from KW, however: should really sort on columns, 

because */ 

/* it's not necessariliy last; could sometimes be a different 
order. */ 
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if (result — SUCCESS) 

{ 

f ile_area->maxlen = (file_area->firstfield->column) + 

(f ile_area->f irstfield->length) - 1; 

dasgcluster (vl, &c2) ; 

/* very last thing to do before leaving: calculate offsets for 

*/ 

/* buffer fields. Routine sort_of fsets, below, does this. */ 
result = sort_offsets (file_area->firstfield, tl) ; 

) 

return (result) ; 

} /* end f ile_asgncluster */ 
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Figure 5 File First and Next 


# include "chap4std.h" 

# include cctype . h> 

/*************************************************************/ 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


File: 6file_ops.c 
Module: scracc 

contains functions read, write & insert (plus utilis) 
for FITS and general file clusters 
Routines: 

f ile_insert 
f ile_f irst 
file next 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 


/* 



/* 

Function: file first 

/* 

File: 

6f ile_ops . c 

/* 

Author : 

M . Moroh 

/* 

Last Update: 8/88 

/* 



/* 

Read first 

record of gem 

/* 

Called by 

/scracc/62i.c 

/* 




/*************************************************************/ 

/ + ********************************/ 

*/ 
*/ 
*/ 
*/ 
*/ 
V 

il files and files of FITS */ 

:>utine generic_f unction */ 

*/ 

/*************************************************************/ 
char *calloc() ; 
void free() ; 

#define NEW_LINE '\n' 

/* read first record of a generic file into a buffer */ 
file_first (vl,cl, tl) 

VGA *vl ; /* vca pointer */ 

CCA *cl; /* pointer to CCA */ 

/*for host version of resident cluster */ 
TCA *tl; /* tea for table corresponding to file */ 

{ 

int result; 
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/* first, rewind the tape (or reposition the disk, or whatever) 
*/ 

/* NOTE: This routine is probably system dependent. */ 

result = f ile_rewind(cl->res_f ile_ptr) ; 
if (result == SUCCESS) 

result = read_past_hdr (cl) ; . . , . , 

if (result == E_E 0 F_ON_F I LE_H DR ) result = f ile_rewind (cl- 

>res_f ile_ptr) ; 

if (result == SUCCESS) 

result = file_next (vl,cl,tl) ; 

> 

return (result) ; 


) /* end file_first */ 
/*********************************************************/ 
/* 

Function: file_next 
File: 6file_ops.c 

Author : M . Moroh 

Last Update: 4/90 - KW add binary types 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


Read next record of general files and files of FITS 
Called by /scracc/62i.c routine generic_function 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 


/*********************************************************/ 

/* Routine to read the next record of a generic file into 

/* remember - assign file already read file header cluster */ 
/* and puts header info into cl->res_areas */ 

y *********************************************************/ 


f ile_next (vl , cl , tl ) 

VCA *vl; /* vca pointer */ 

CCA *cl ; /* pointer to CCA for host version of 

resident cluster */ . . _ . n . . 

TCA *tl; /* tea for table corresponding to file */ 


{ 

AFIELD *eachf ield; 
AFIELD *last ; 
AFIELD * first field ; 
int length; 


/* for allocating fieldinfo */ 

/* to find length of record */ 

/* beginning of record (1st field) */ 

/* for calculating field lengths */ 
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char *datarec ; 
char *item; 

FIELD *fpointer; 

FIELD *find data item() ; 

FIELD */ ~ 

int itemlen; 

int input_length ; 

char *place; 

int Jc; 

char *file_format; 

int i; 

int c; 

int anint? 

float afloat; 

int errorcode = OK; 

union { 

char c [ 4 ] ; 
short s; 
int i ; 

} utype ; 


/* buffer for a record of data */ 
/* buffer for an item of data */ 

/* function find. . . returns ptr to 

/* length of a field */ 


/* allocate storage for the file record */ 

row assign “ PUt int ° ° Ca special area cl->res_area by table- 
record^°*/ llDCate storage for a data item (max size: whole 
Ces^filfjtr)” 1 */ 3 resident file Pointer of %d“, cl- 

>nppt« n “ ( %^, l0giCal P ° int6rs in buffer: tl->nlptrs is %d, tl- 

tl->nlptrs / tl->npptrs) ; */ 

input_length = cl->res_area->maxlen + l; 
datarec = (char * ) calloc(l, input_length) ; 
item - (char * ) calloc(l, input_length) ; 

^r‘:::r:::r**‘**r*:****‘******‘*‘**‘***************‘*******v 

c=EOS ; 

while (( i < input_length-l ) && ( C != EOF)) 


c= getc (cl->res_f ile_ptr) ; 

!= 'i n ' } && (c!= E0F)) datarec[i++] = c; 

/ maybe m future versions more ending characters should be 
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included */ 

} 

datarec [ i++ ] = EOS ; 

/* if (c ! = EOF) printf ("\n the data record image: %s'\ datarec); 
*/ 

if ( C == EOF) /* end of file */ 
errorcode = EOT; 


/* now go through the data, field by field. Convert, it to the*/ 
/* corresponding host format and move it to the host buffe / 

else 

firstfield = cl— >res_area— >f irstf ield, > . f fioin 

eachfield = firstfield; /* start at beginning of field 

list */ 

} 

/* REMEMBER: FIELDS COME OUT BACKWARDS */ 

while (eachfield != NULL && errorcode == OK) 

{ 


*/ 


/* convert the data to the corresponding host data type 
/* the file data item is called item; the host item, */ 


place = (datarec - 1) + eachf ield->column; /* ptr to place 
ln ^bfSacopyt item, place, eachf ield->length) ; /* copy from file 

record ( i*/ n+ e a c h fiei d ->ien g th) = EOS; /* add end of 

string mark */ 

/* printf ("\n item to decode is %s; its len is %d",i- 
tem,strlen(itemn^ / skip conversion table. Use only DAVID data 

type /i *do this by giving the ce pointer (to conversion table) a 

nUl ^cl->res_area->ce = NULL; /* for testing — see above 

lines */ 

/* find the name of the data item in the TCA of the main 
cluster V fpolnter ls a ptr to the field in the TCA of the main 

ClUS /* r p rintf ( M \n in file_next, about to look for field 

f pointer = f ind_data_i tern (tl, eachf ield->name) , 
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if (f pointer == NULL) 

{ 

/* print f (" \n CANT FIND FIELD IN ARBI FILE: %s", eachf ield- 
>name) ; */ 

errorcode = E_CANT_FIND_ARBI FIELD ; 


/* it may be necessary to convert the FILE'S format types to 
lower case */ 

fil e _f or mat = calloc(l, strlen (eachf ield->type) + 1 ); 

strcpy ( f ile_f ormat , eachf ield->type) ; 
lower_case (f ile_format) ; 

/* Transfer the data to the DAVID buffer */ 

/*********Fiie and DAVID are both char or or both num 
***************/ 

if (( (strncmp (file_f ormat, "char",4) == 0) && (fpointer->type 
== TCHAR) ) | | 

^^ rncin P format, "num" , 3) == 0) && (fpointer->type 

/* stick the char string item right in the buffer */ 

bfwdcopy ( (tl->buf_ptr + *0FFSET(tl, fpointer->id) ) , item, 
strlen (item) ) ; ' 

) 


/**** File is ASCII integer; DAVID is integer data ********/ 
else if ( ( (strncmp(file format, "int", 3) ==0) && (fpointer- 
>type == TINT) ) | | “ 

( (strncmp (f ile_format, "num" , 3) ==0) && 
(fpointer->type == TINT))) 

sscanf (item, "%d",&anint) ; 

/* P u ^ the host version of the data item into the host 
buffer */ 

bfwdcopy ( (tl->buf_ptr + *0FFSET(tl, fpointer->id) ) , 

( (char *) &anint) , fpointer->length) ; 

) 


/**** File is Binary integer 14; DAVID is integer ****/ 
>type T j^t^) i f [ * ^ strncm P (f ile_f ormat, "i4" , 2) ==0) && (fpointer- 


( fpointer->type==TNUM) ) ) 
{ 


( (strncmp (file_format, M i4" , 2) ==0) && 


bfwdcopy ( (tl->buf_ptr + *0FFSET(tl, fpointer->id) ) , 
item, fpointer->length) ; 
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/**** File is binary integer 12 ; DAVID is integer INT 

***/ 

else if ( (strncmp(file_format, "i2",2)==0) && (fpointer- 
>type==TINT ) ) 

/* First convert to short integer */ 
bfwdcopy (utype.c, item, 2) ; 

/* convert to regular integer */ 
anint = utype.s; 

/* Copy to DAVID buffer */ 

bfwdcopy ( (tl->buf ptr + *OFFSET(tl, fpointer- 
>id) ) , (char *) fianint, sizeof (int) ) ; } 

/**** FILE is ASCII floating point and DAVID is floating 
point */ 

else if ( (strncmp(file_format,"float",5)==0) && 
(fpointer->type == TFLOAT) ) 

{ 

sscanf (item, "%f" , Safloat) ; 

bfwdcopy ( (tl->buf_ptr + *OFFSET(tl, fpointer->id) ) , 

( (char *) fcafloat) , fpointer->length) ; 

) 

/**** FILE is binary 4 byte floating and DAVID is 
floating point ****/ 

else if ( (strncmp(file_format, "r4",2)==0) && (fpomter- 

>type ==TFLOAT) ) 

bfwdcopy (( tl — >buf_ptr + *OFFSET(tl, fpointer— >id) ) , item, 

fpointer->length) ; 

} /* end of floating point handling */ 

else 

( /* An unexpected condition has occurred */ 

printf ( "Unexpected condition—Data mismatch in main + aux 

) § 

printf ("Item = %s, type in aux = %s, type in DAVID is 

%d» 

item, file_format, fpointer->type) ; 

} 


/* now do the same for the next field in the file record */ 

cfree (f ile_format) ; /* JWF */ 

eachfield = eachf ield->next ; 

} /* end of WHILE loop */ 


Contract NASS 30304 - Final Report 


Page 82 



Illustrations 


cfree(item) ; /* jwf */ 
cfree (datarec) ; /* jwf */ 
return (errorcode) ; 

} /* end of file_next */ 


Contract NAS5 30304 - Final Report 


Page 83 



Illustrations 


Figure 6 - File Insert 

/*********************************************************/ 
/* */ 

/* Function: file_insert */ 

/* File: 6file_ops.c */ 

/* Author: M. Moroh */ 

/* Last Update: 4/90 */ 

/* Add binary types */ 

/* */ 

/* Routine to insert records into a generic file from */ 

/* DAVID buffer . */ 

/* Called by /scracc/62i.c routine generic_function */ 

/* */ 

/*********************************************************/ 
f ile_insert (vl , cl , tl) 


VCA *vl; /* vca pointer */ 

CCA *cl; /* pointer to CCA */ 

TCA *tl? /* tea for table corresponding to file */ 

AFIELD *eachfield; /* for allocating fieldinfo */ 

AFIELD *last; /* to find length of record */ 

AFIELD *firstfield; /* beginning of record (1st field) */ 

int length; /* for calculating field lengths */ 

char *datarec ; /* buffer for a record of data */ 

char * item ; /* buffer for an item of data */ 

FIELD *fpointer; 

FIELD *f ind_data_item( ) ; 

int itemlen; /* length of a field */ 

int input_length ; 
char *place; 
int k; 

char *f ile_format ; 
int i; 
int c; 
int anint; 
float afloat; 
char *s ; 
char *ptr; 
char *temp; 
int *int_ptr; 
int errorcode = OK; 
short *short_ptr, ashort; 
union { 
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char c [ 4 ] ; 
short s; 
int i ; 

} utype ; 

/* allocate a data record (datarec) for file stuff, */ 

/* and a variable (item) for each field to get from DAVID. */ 

input_length = cl->res_area->maxlen +1? 
datarec = calloc(l, input_length) ; 
temp = calloc(l, input_length) ; 

/* Initialize the buffer to blanks */ 
for (i = 0; i < input_length; i++) 

♦(datarec + i) = ' '; 


/* go through the data, field by field in the aux cluster. Con- 
vert it to the */ 

/* corresponding resident format (if nec) and move it to the host 
buffer */ 


firstfield = cl->res_area->f irstf ield; 

eachfield = firstfield; /* start at beginning of field list */ 

/* REMEMBER: FIELDS COME OUT 


BACKWARDS */ 


while (eachfield ! = NULL && 

(fpointer = find_data_item(tl,eachfield->name) ) != 

NULL) 

{ 

/* printf("\n the field we're working on is %s" , eachfield- 
>name) ; */ 


/* place is a pointer to the position of this field in the 
data record */ 

place = (datarec - 1) + eachfield->column; 


/* for testing: skip conversion table. Use only DAVID data 

types. */ 

/* Do this by giving the ce pointer (to conversion table) a 
null value. */ 

cl->res_area->ce = NULL? /* for testing — see above 

lines */ 

/* it may be necessary to convert the FILE'S format types 
to lower case */ 

file_format = calloc(l,strlen(eachfield->type) + 1); 

strcpy ( f ile_format , eachf ield->type) ; 
lower_case (f ile_format) ; 
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/********** DAVID data was CHAR or NUM. File is ASCII 
**************/ 

if ( ( (strncmp(file_format, "char", 4) == 0) && 

( fpointer->type == TCHAR) ) | | 

( (strncmp(file_format, "num", 3) == 0) && (fpointer->type 
== TNUM) ) ) 

{ 

/* Copy the data from the DAVID buffer to 
datarec. Note that the 

DAVID buffer item will contain an EOS if it less than 
the maximum 

field length; hence the following routine: 

*/ 

ptr = (char *) (tl->buf_ptr + 

♦OFFSET ( tl, fpointer->id) ) ; 

copy_no_eof (place, ptr, fpointer->length) ; 

} /* end of if item is char or num */ 

/*♦** DAVID data type is INT. File is ASCII (called INT OR 
NUM) ****/ 

else if ( ( (strncmp(file_format, "int" ,3) == 0) && 

( fpointer->type == TINT)) || 

( (strncmp (f ile_format , "num" , 3) == 0) && ( fpointer->type 

== TINT) ) ) 

{ 

bfwdcopy ( (char *)&anint, (tl->buf_ptr + 

♦OFFSET (tl,fpointer->id) ) , 

sizeof (int) ) ; 

/* printf("\n INTEGER value about to be put on file is 
%d\n", anint) ; */ 

spr int f (temp, "%*d" , eachf ield->length, anint); 

co py_ no _eof (place , temp, strlen (temp) ) ; 


} 


/* for (k = 0; k < eachf ield->length; k++) 

printf (place + k) ; 

*/ 

/* end of if item is int */ 


/****DAVID type is INT; FILE type is 14 binary integ- 
er****/ 

else if ( (strncmp(file_format, "i4",2)==0) && 

( fpointer->type == TINT)) 


{ 


bfwdcopy 

♦OFFSET (tl , fpointer->id) ) 


((char *) Sanint, (tl->buf_ptr + 
/ 

sizeof (int) ) ; 
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ptr = (char *) (&anint) ; 
bfwdcopy (place, ptr, sizeof (int) ) ; 


/****DAVID type is int; FILE type is 12 binary integer 


****/ 

else if ( (strncmp(file_format, ,, i2" , 2)==0) && (fpointer- 
>type == TINT) ) 

{ 

/* copy to an integer for alignment */ 
bfwdcopy ((char *) Sanint , (tl->buf_ptr + 

♦OFFSET (tl,fpointer->id) ) , 


sizeof (int) ) ; 
/* convert to short */ 
ashort = an int; 
ptr = (char *) (&ashort) ; 
bfwdcopy (place, ptr, 2); 


} 

/******* DAVID data type is float; file type is float but 
data's ascii ***/ 

else if ( (strncmp(file_format, "float", 5) == 0) && 
(fpointer->type == TFLOAT) ) 

{ 


sprintf (temp, "%* . *f " ,13,6,* (tl->buf_ptr + 
♦OFFSET (tl, fpointer->id) ) ) ; 


bfwdcopy ( (char *)&afloat, (tl->buf_ptr + 

♦OFFSET ( tl, fpointer->id) ) , 

sizeof ( float) ) ; 

sprintf (temp, "%* . *f " , eachf ield- 
>length,eachfield->nodecs, afloat) ; 

copy_no_eof (place, temp, strlen( temp) ) ; 

> 

/****DAVID type is FLOAT and FILE type is binary float 
(R4 ) ***♦/ 

else if ( (strncmp (f ile_format, "r4" , 2) ==0) && (fpointer- 
>type==TFLOAT ) ) 

{ 

/* Both are binary so just byte copy one to other 


*/ 


ptr = (char *) (tl->buf_ptr + 
♦OFFSET (tl, fpointer->id) ) ; 

bfwdcopy (place, ptr, fpointer->length) 
} /* end if item is float 
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/* here add code to decode other data types. */ 
else printf("\n item %s didn't match appropriate DAVID 
data type” , 


eachf ield->name) ; 


/* Prepare for next iteration of field loop */ 
eachfield = eachf ield->next; 
cfree(file_format) ; /* JWF */ 

} /* now do next item */ 


if (fpointer == NULL) 

errorcode = E_CANT_FIND_ARBI_FIELD; 

else 


{ 

*/ 


/* now write the record. The contents are in datarec. 

for (i = 0; i < input_length - 1; i++) 

{ 

c = * (datarec + i) ; 
putc (c, cl->res_f ile_ptr) ? 

} 


c = NEW_LINE ; 

/* Put a newline on the end of the record for readability 

*/ 

/* NOTE: change DEFINE for NEW_LINE if don't want one. 
Some files dont?*/ 

putc(c / cl->res_file_ptr) ; 


) 


/* Print the record for debugging 
* (datarec+input_length-l) = EOS; 

printf("\n the record just written is %s" , datarec); */ 


/* Cleanup and return */ 

cfree( datarec) ; /* JWF */ 

cfree(temp) ; /* JWF */ 

return (errorcode) ; 

} /* end file_insert */ 
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Figure 7 - File Deassign 

/***************************************************/ 

/* File is 62E.C ** GENERIC DEASSIGN CLUSTER */ 

/***************************************************/ 

#include "chpt6std.h" 

gdeasgncluster (vca , cca) 

VCA *vca; 

CCA *cca; 

{ 

int errorcode; 

CCA *cluster_ptr , *next_cluster ; 

/********************* f 

/* Beginning of code */ 

/*********************/ 
errorcode = OK; 

/*if (cca->structure >= FIRST_ARBI) JWF - will do for 
ARBI_FITS only 

for now. */ 

if (cca->structure == ARBI_FITS) 

errorcode = arbi_deasgncluster (vca, cca) ; 

else 

if ( (errorcode == OK) && ( (errorcode=david_deasgnclus- 
ter(vca,cca) )==0K) ) 

errorcode=deassign_cluster (vca, cca) ; /* chpt 7 deassign */ 


if (errorcode == OK) 

{ 

/* Delete cluster pointer from chain in VCA */ 
next_cluster=cluster_ptr=vca->clusters; 

/* Find the cluster's position in the chain */ 
while (next_cluster != NULL) 

( if (next_cluster == cca) break; 
else 
( 

cluster_ptr=next_cluster ; 
next_cluster=cluster_ptr->next ; 

) 

)/* end of while */ 
if (cluster_ptr == next_cluster) 

{ 

if (cluster_ptr == NULL) vca->clusters = NULL; 
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else vca->clusters = cluster_ptr->next ; 

) 

else if (next_cluster — cca) cluster_ptr->next = cca->next; 

} 

else set_status ( vca , errorcode) ; 

return (errorcode) ; 

} /* end of gdasgncluster */ 

/**************************************************/ 

/* File is 62E1.C ** DAVID DEASSIGN CLUSTER */ 

/**************************************************/ 

david_deasgncluster (vca , cca ) 

VCA *vca; 

CCA *cca; 

{ 

CCA *next_cluster ; 
int errorcode; 

/it********************/ 

/* Beginning of code */ 

/*********************/ 

/* Close the file, if this is the only assigned cca from file. */ 
next_cluster=vca->clusters ; 
while (next_cluster != NULL) 

if ( (next_c luster 1= cca) && (next_cluster->file == cca->file) ) 
break ; 

else next_cluster = next_cluster->next; 
if (next_cluster == NULL) close_f ile (vca,cca->f ile) ; 

/* Deallocate all the memory which was allocated by assign clus- 
ter */ 

if (strncmp (cca->name, "DIRECTORY" , 9) == 0) 

{ free_cca (cca) ; errorcode = OK; } 
else 

if (strncmp(cca->verify,CCA_VERIFY,sizeof (cca->verify) )==0) 

{ 

alloc_deassign (cca) ; 
errorcode=0K ; 

} 

else 

errorcode=E NOT CCA; 
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return (errorcode) ; 

} /* end of david_deasgncluster */ 

/*************************************************************/ 
/* File is 62E2.C ** ARBI DEASSIGN CLUSTER */ 

/* Code added 8/88 by MM to do the ARBI part of assign cluste*/ 
/*************************************************************/ 

arbi_deasgncluster ( vca , cca) 

VCA *vca ; 

CCA *cca ; 

{ /* begin function */ 

int errorcode = OK; 

/ft*******************/ 

/* Code begins here */ 

/********************/ 

FF_AREA *file_area; 

AFIELD *eachfield, *next_one; 

/*************************************************/ 

/* FILE *fopen(); 
int k; 

char item [ 4 ] ; 

*/ 

/* If a resident with a file, close the file (its ptr is in the 
CCA) */ 

if (fclose (cca->res_f ile_ptr) != 0) errorcode = E RES FI- 
LECLpSE ; “ 

/* Cleanup — Free allocated storage */ 

eachfield = cca->res_area->firstfield; 
next_one = eachf ield->next ; 
while (eachfield != NULL) 

{ 

cfree (eachfield) ; 
eachfield = next_one; 
if (eachfield != NULL) 

next_one = eachf ield->next; 

} 

cfree (cca->res_area) ; /* jwf */ 


/* JWF */ 

/* JWF 02/01/90 */ 
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if (strncmp(cca->verify,CCA_VERIFY, sizeof (cca->verify) ) ==0) 
alloc_deassign(cca) ; 

else 

errorcode=E_NOT_CCA ; 
return (errorcode) ; 

} /* end arbi_deasgncluster */ 
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Figure 8 - Generic Template for Definition Generator 


Note: Blank lines are for readability only!! 


/********* Th i s 

0 0 invoke_dbms 
DBMS */ 


section defines the database ********/ 

& /* these 3 commands bring up the 


00give_password 0RUID 00separator 0RPWD /* and give it the 
definition */ 

/********** Above section defines the database *********/ 


/*********************************************************/ 

/**** Below section provides the database definition ***/ 

00dbname_keyword @@dbname_pref ix 0DBNAME 00dbname suffix & 
@@db_left_delim & 

/* below is for relational DBMSS */ 

§BEGINTABLE<@@table_separatorx@@table_left_ delim> & 

@§table_name_keywd 00tbname_pref ix 0 TABLE NAME 00tbname suf- 
fix ~ - 

/* above fields are for relational DBMSs */ 


0BEGINFIELD<00field_separator><0@ field left delim>& 

<00f ield_rt_delim> 

00field_attribute_left_delim & 

00f ield_name_keywd 0RFNAM 00f ield_attribute_separator & 

00f ield_type_keywd 0RFTYP & 

0BEGINLENGTH<00field_length_sepx0@field_length left delim> 

& 

<00f ield_length_rt_delim> 0RFLEN 0ENDLENGTH & 

00f ield_attribute_separator & 

00field_size_keywd 0RFLEN 
0BEGINFPOS 00f ield_attribute_separator & 

00f ield_start_pos_keyword 0RFPOS 0ENDFPOS 
0BEGINFCOM 00f ield_attrib_sep & 

00f ield_comment_keywd 0RFCOM 0ENDFCOM & 
00field_attribute_right_delimiter & 

00f ield suffix 
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GENDFIELD 

@@field_terminator 

GENDTABLE 

§ @db_r ight_del im 
G@db_terminator 

@@exit /* this command exits the database */ 
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COMMENTS : 

Ab° v e is a generalized template. It was made to include all 
possinties. Items may be absent for a specific DBMS, and order 

^ b ® <* lfferent from the way they're specified above. 
Keywords may either precede or follow the associated value. 

Note: there are no longer default assumptions about carriaqe 
returns; they will be specifically inserted into the DBMS- 
dependent template as ,, \n"s. 

PARPN? f on?S Se field ® a £ e database type specific. For example, 
PARENT oniy occurs in type 2 (hierarchical) databases. Network 

SS??, (°™}er, member) only appears in type 3 (network) databases. 

fj?® a ', f ^ le f nd area Wl11 n °t appear in type 1 (relational), 
type 4 (micro) or type 5 (generic file) DBMSs. 

iS f ° r a descri Ption of an item that appears 
before the loop for that item: e.g., FIELD DESCRIPTION. It'll 
appear exactly once, no matter how many fields there are. 

P 1 ® f ^ eld iength information is filled in from the datatype 
table. That table will accompany the template. 

^v^Zi The s fP arat< ? rs and delimiters appear in the template 
will be fTn • Wll ^u n th f fi na l template, i.e., the §@ symbols 
for thlse items*" “ real lten,s like rather than s l™ b ° ls 
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Figure 9 Defining an ORACLE database 


$UFI userl/mypwd 

CREATE TABLE courses 
(dept char (4), 
course char (9) , 
sec# number ( 2 )) ; 

CREATE TABLE teachers 
(id# number (4) , 
instruct char (10) , 
dept char ( 4 ) ) ; 

CREATE TABLE students 
( studid number ( 4 ) , 
studname char (30) , 
ma j or char ( 4 ) ) ; 

CREATE TABLE transcripts 
(semester char (6), 
year number ( 4 ) , 
studid number (4) , 
course char (9), 
sec# number (2), 
grade char ( 1 ) ) ; 

EXIT 
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Figure 10 - Generalized ORACLE Template 


@ BEGINTABLE< \n> 
create @TABLENAME (\n 
§BEGINFIELD< , \n> 

0RFNAM = 0RFTYP 

0BEGINLENGTHOOO 0RFLEN 0ENDLENGTH 
0ENDFIELD ) 

0ENDTABLE 

\n 
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Figure 11 GENERALIZED TEMPLATE FOR Type 2 Database Definition 


Note: Blank lines are for readability only!! 

/ ********* This section defines the database ********/ 

©@invoke_dbms & /* these 3 commands bring up the 

DBMS */ ...... 

00give_password 0RUID ©©separator ©RPWD /* and give it the 

definition */ 

/********** Above section defines the database *********/ 

/***************************************************************/ 
/******* Below section provides the database definition ******/ 

©0dbname_keyword ©©dbname_pref ix ©DBNAME ©©dbname_suf f ix & 
0©db_left_delim & 

/******* Below 2 statements are for hierarchical/network DBMSs 
***/ 

0©file_name keyword ©file_name ©©f ile_name_terminator 

©@area_name keyword ©area_name ©©area_name_terminator 

& 

/******* Above statements are for hierarchical/network DBMSs 
***/ 

/* below fields are for hierarchical/network DBMSs */ 
@©table_header /* mt takes care of this as text */ & 

©@BEGINTABLE<©©table_separator><©0table_left_delim>& 

< © © tab 1 e_r t_de 1 im 

©©table attr_left_delim & . 

0©table_name_keywd ©©tbname prefix ©TABLE_NAME ©0tbname_suf f ix 

©BEGINPAR @©table_attr_sep ©©parent_keywd © PARENT_NAME ©END- 
PAR 

©BEGINTLEN @@table_attr_sep & 

©©table_length_keywd ©TABLE_LENGTH ©ENDTLEN 
©BEGINTPOS @@table_attribute_sep & 

@@table_start_pos_keywd © T ABLE_S TART_POS ©ENDTPOS 
©BEGINTCOM @@table_attr_sep & 
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00table_comment_keywd 0TABLE COMMENT 0ENDTCOM & 

00table_attr ibute_r ight_del im 

/* above fields are for hierarchical DBMSs */ 

/* below is for relational DBMSS */ 

@ fl« GINTABLE<@etable - separator><eetable - left _ delim> & 

@@tbname_prefix @TABLE_NAME 00tbname_suf- 
/* above fields are for relational DBMSs */ 

0BEGINFIELD<0@field_separatorx@@field left delim>& 

<00 f ield_rt_delim> 

00field_attribute_left_delim 

Jf f ifld_name_keywd 0RFNAM 0 0 f ield_attr ibute separator & 

00f ield_type_keywd 0RFTYP & 

& @ BEGINLENGTH< 00f ield_length_sep><00f ield_length_left_delim> 

<00field_length_rt_delim> 0RFLEN 0ENDLENGTH & 
ield__attribute_separator $ 

ield_jsize_keywd @RFLEN 
0BEGINFPOS ield_attribute_separator & 
00field_start_pos_keyword 0RFPOS 0ENDFPOS 
0BEGINFCOM 00f ield_attrib_sep & 

0 0 f ie 1 d_coxtunen t_keywd 0RFCOM 0ENDFCOM & 
00field_attribute_right delimiter & 

00f ield_suf f ix 

0ENDFIELD & 

00field_terminator 

0ENDTABLE f 


it************ below-only for NETWORK/HIERARCHICAL DBMSs 


00network_header 

& 


/* mt takes care of this as text to copy*/ 


0BEG I N SET< 0@ se t — s e p >< §@s e t_left_delim><00set right delim> /*mt: 
no*/ & — ' 

dS™ 6 *" - name_: keyword 0SET_OWNER_NAME 00set_name sep 0SET MEM- 
BER NAME & — 


/* note: in previous line, order can be reversed 
00set_attribute_left_delim /* mt: no */ & 

00set_owner_keyword 0SET_OWNER_NAME 00set attribute 
00set_member_keyword 0SET_MEMBER_NAME & 

00set_attribute_right delim /* mt: no */ & 

0ENDSET ~ ' r 


*/ 

separator 


& 
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/********** above - only for NETWORK/HIERARCHICAL DBMSs 
**********/ 


§ 0 db_r ight_de 1 im 
00db_terminator 

00exit 


/* this command exits the database */ 
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COMMENTS : 

Above is a generalized template. It was made to include all 
possilities. Items may be absent for a specific DBMS, and order 
of items may be different from the way they're specified above. 
Keywords may either precede or follow the associated value. 

Note: there are no longer default assumptions about carriage 
returns; they will be specifically inserted into the DBMS- 
dependent template as "\n"s. 

Some of these fields are database type specific. For example, 
FABENT only occurs in type II (hierarchical) databases. Network 
stuff (owner, member) only appears in type III (network) data- 
bases. Schema, file and area will not appear in type I (rela- 
tional) , type IV (micro) or type V (generic file) DBMSs. 

The item "header” is for a description of an item that appears 
before the loop for that item: e.g., FIELD DESCRIPTION. It'll 
appear exactly once, no matter how many fields there are. 

The fieid length information is filled in from the datatype 
table. That table will accompany the template. 

NOTE: 3/20/89 

The separators and delimiters appear in the template exactly as 
they will in the final template, i.e., the @@ symbols will be 
filled in with real items like rather than symbols for those 
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Figure 12 Typical TEMPLATE FOR Type 2 Database 


DBD NAME= @ DBNAME - 1 \n 
ORFrTWTART E<\n^ 

SEGM NAME=@TABLENAME , PARENT=@PARENTNAME , BYTES=§TABLELENGTH \n 
@BEGINFIELD<\n> 

FIELD NAME=@RFNAM 

§BEGINLENGTH<>< , BYTES=><> 0RFLEN §ENDLENGTH 

, START=@RFPOS 

@ENDFIELD 

0ENDTABLE 


\n 
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Appendix 1 - Installing Template Generator Software 

The template generator is written using a software platform 
called the Intelligence/Compiler, a product of Intelligence- 
Ware, Inc. The user is supplied with a runtime version only. 

The steps listed below explain what must be done to install 
the 

software. 

1. The AUTOEXEC.BAT file in the root directory must be 
modified so that the path is extended and so that a line is 
added to set an environment variable for the Intelligence/Com- 
piler. Include the following: 

PATH = <whatever was in path previously>; C:\IC; 

SET ICPATH=C:\IC 

2. The CONFIG.SYS file in the root directory must be 

modified to provide for enough files and buffers: (The num- 

bers shown here are the minimum to be specified.) 

FILES = 12 
BUFFERS = 8 

3. Make a new directory under the root. Call it IC. (If a 
different directory name is used, change the modifications to 
your AUTOEXEC.BAT accordingly.) The following set of files 
are supplied to be put in the \IC directory: 

ICX.EXE 
ERRORS . SYS 
HINSTALL.EXE 
IC . BAT 
IC.DD 

IC-COLOR. EXE 
ICP.EXE 

4 . Make three additional directories if you want to 
generate all three types of templates: for defining a database 
in a relational database language, for defining a database in 
a hierarchical or network database language, and for database 
queries. 
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The first directory will contain the module to run 
sessions of type 1 and 2a (see overview) . The module gener- 
ates templates for defining databases in relational database 
languages. I suggest this directory be called \IC\DAVID and 
will refer to it below using this name. However, a different 
directory name could be used. 

The second directory will contain the module to run 
sessions of type 1 and 2b. The module generates templates for 
defining databases in hierarchical or network database lan- 
guages. I suggest this directory be called \IC\DAVIDH and 
will refer to it below using this name. However, a different 
directory name could be used. 

The third directory will contain the module to run 
sessions of type 3 and 4 . The module generates templates for 
database queries. I suggest this directory be called \IC\DA- 
VIDQ and will refer to it below using this name. However, a 
different directory name could be used. 

A unique set of files is supplied for each of the 
three directories. The installation disks are clearly marked 
indicating which files should be saved in \IC\DAVID, which in 
\IC\DAVIDH , and which in \IC\DAVIDQ. All of these files are 
of the form * . BAT or *.ICP or *.FRM or *.LST . 

5. For each of the directories made in Step 4, there must 
be a subdirectory called EXAMPLE. Therefore if in Step 4 you 
created the directory called \IC\DAVID, there should now be a 
directory called \IC\DAVID\EXAMPLE. 

Similarly create \IC\DAVIDH\EXAMPLE and \IC\DAVIDQ\EXAM- 
PLE if indicated. 

These directories will be used to save examples 
entered during previous sessions so that they can be reused 
and modified as desired. A few samples are included in the 
installation disks and are clearly marked indicating which 
files should be saved in \IC\DAVID\EXAMPLE, which in 
\IC\DAVIDH\EXAMPLE, and which in \IC\DAVIDQ\EXAMPLE. 
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Appendix 2 - Running T68 

If you want to generate a template for a defining a database 
in a relational database language: 

1. Get into the directory \IC\DAVID. 

2. First, run a session to generate log-on and log-off 
templates. Start this session by typing DAVIDO (ending with 
the number 0) . 

3. Second, run a session to generate the complete tem- 
plate. Start this session by typing DAVID or BIGDAVID. DAVID 
is appropriate for entering information about a database 
language which is not too verbose: i.e. The language does not 
use a lot of punctuation or long keywords, etc. BIGDAVID is 
appropriate for more verbose languages. If you get an error 
message saying you ran out of memory during a session started 
by typing DAVID, rerun the session using BIGDAVID. DAVID is 
somewhat faster, but BIGDAVID can be used for all cases. 

4. At the end of the session there will be two new files 
recorded to disk in the current directory. These files are 
called TEMPLATE and TYPETABL. Before running another ses- 
sion make copies of these files in another directory (possibly 
renaming them) , if they are to be saved for future use. 

If you want to generate a template for a defining a database 
in a hierarchical or network database language: 

1. Change to the directory \IC\DAVIDH. 

2. First, run a session to generate log-on and log-off 
templates. Start this session by typing DAVIDHO (ending with 
the number 0) . 

3. Run a session to generate the complete template. 

Start this session by typing DAVIDH or BIGDAVH or VBIGDAVH. 
DAVIDH is appropriate for entering information about a data- 
base language which is not too verbose: i.e. The language does 
not use a lot of punctuation or long keywords, etc. BIGDAVH 
is appropriate for more verbose languages and VBIGDAVH for 
even more verbose languages. If you get an error message say- 
ing you ran out of memory during a session, rerun the session 
using a version capable of handling a more verbose language. 
DAVIDH is faster than BIGDAVH which in turn is faster than 
VBIGDAVH, but VBIGDAVH can be used for all cases. 
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4. At the end of the session there will be two new files 
recorded to disk in the current directory. These files are 
called TEMPLATE and TYPETABL. Before running another session 
make copies of these files in another directory (possibly 
renaming them) , if they are to be saved for future use. 

If you want to generate a template for a database query: 

1. Change to the directory \IC\DAVIDQ. 

2. First, run a session to generate log-on and log-off 
templates. Start this session by typing DAVIDQO (ending with 
the number 0) . 

3. Second, run a session to generate the complete tem- 
plate. Start this session by typing DAVIDQ. 

4. At the end of the session there will be three new 
files recorded to disk in the current directory. These files 
are called TEMPLATE and BOOLTABL and LCTABL. Before running 
another session make copies of these files in another direc- 
tory (possibly renaming them) , if they are to be saved for 
future use. 
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Appendix 3 - TGS Detailed Information 

The software for each session is modularized so that it can 
fit into available memory. If you are using a lot of memory 
resident software, you might have to disable some of this 
software to allow the Intelligence/Compiler software to run. 

As each module is being loaded from disk, a load bar appears 
at the bottom of your screen showing the progression of the 
load. 

The modules being loaded are identified on disk with the 
extension *.ICP. Each module has a specific logical task to 
perform in the reasoning process. When a module starts to 
execute, messages usually appear on the screen telling the 
user what that module is trying to do. 

The tables below show the logical tasks performed by each mod- 
. it should be noted that not all modules in a directory 
are invoked during the same session. 
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MODULES in \IC\DAVID 

DAVIDO Generates introductory and exit templates 

DAVID1A Elicits a sample statement from the user and parses 
it 

DAVID1C Looks for: 

1) database name keywords, table name keywords, 

and field name keywords 

2) various delimiters 

DAVID1D Looks for: 

1) things we call database delimiters 

2) various separators, suffixes, and terminators 

3) any extra lines which we can't account for 

DAVID1E Looks for: 

1) things we call database delimiters 

2) any extra lines appearing after the line 

containing 

the database name but before 

the line describing the first table 

3) something we call the database name suffix 

DAVID1F Looks for: 

1) various things we call separators, suffixes, 

and terminators 

2) any extra lines appearing after the last table 

description 

DAVID2A Elicits information about field definitions from the 
user 

DAVID2B Constructs the field definition template 
DAVID3A Generates a template for database definition 
DAVID3B Elicits information about data types from the user 
DAVID3C Generates the final TEMPLATE and TYPETABL 


Contract NAS5 30304 - Final Report 


Page 108 


Appendixes 


MODULES in \IC\DAVIDH 

DAVIDHO Generates introductory and exit templates 
DAVIDH1A Elicits a sample statement from the user and parses 


DAVIDH1C Looks for: 

1) database (or schema) name keywords, record name 

keywords, and field name keywords 

2) various delimiters 


DAVIDH1C1 Looks for database (or schema) name keywords 
??I^= H1C2 Looks for recor d name keywords and associated deli- 


DAVIDH1C3 Looks for field 
miters 


name keywords and associated deli- 


DAVIDH1D 

1 ) 

2 ) 


3 ) 

4 ) 


DAVIDH1E 

1 ) 

2 ) 


3 ) 

DAVIDH1F 

1 ) 

2 ) 


DAVIDH1X 


DAVIDH1Z 


Looks for: 

things we call database (or schema) delimiters 
any extra lines appearing after the line containing 
the database (or schema) name but before 
the line describing the first record 
various separators, suffixes, and terminators 
any extra lines appearing after the last record 
description 


Looks for: 

things we call database (or schema) delimiters 
any extra lines appearing after the line containing 
the database (or schema) name but before 
the line describing the first record 
something we call the database name suffix 

Looks for: 

various things we call separators, suffixes, and 
terminators 

any extra lines appearing after the last record 
description 


Deciphers any extra lines appearing after the line 
containing the database (or schema) name 
but before the line describing the first record 


Figures out how the user supplies information on 
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DAVIDH2A 

DAVIDH2B 

DAVIDH3A 

DAVIDH3B 

DAVIDH3C 


parent- child links 

Elicits information about field definitions 
from the user 

Constructs the field definition template 
Generates a template for database definition 
Elicits information about data types from the user 
Generates the final TEMPLATE and TYPETABL 
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MODULES in \IC\DAVIDQ 


DAVIDQO Generates introductory and exit templates 

DAVI ^DaratiS itS T ***, &X ^ le . f '«» user ; Parses the query; 
lines example into initial, boolean, and ending 


DAVIDQ2 Makes a template from the initial lines 
DAVIDQ3 Makes a template from the boolean lines 


DAVIDQ3B Elicits information from 
and Linguistic Conventions; 
LCTABL 


user about Boolean Operators 
Generates the BOOLTABL and 


DAVIDQ4 Makes a template from the ending 
Generates the whole query template 


lines 
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Appendix 4 - Table Documentation 


To facilitate the creation of templates, the expert system 
will create the following table which will subsequently be 
read by the Interface Driver Program. 

Tvoe Conversion Table 


RESIDENT 

DATA 

TYPE 

TEMPLATE 
TYPE # 

SEPARATOR 
( ® • CJ • • $ • # ) 

CORRESPOND 
DAVID TYPE 

MIN 

LEN 

MAX 

LEN 

DEFAULT 

LENGTH 
















RESIDENT DATA TYPE is columns 1-19 
TEMPLATE TYPE is column 21 
SEPARATOR is column 23 

CORRESPONDING DATA TYPE is columns 25-34 
MIN LEN is columns 36-38 
MAX LEN is columns 40-42 
DEFAULT LEN is columns 44-50 
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DAVID Type Conversion Table 

Values in the third column of the above table come from the 
following table of possible DAVID data types: 


DAVID 

DATA 

TYPE 

DESCRIPTION 

INT 

binary integer 

CHAR 

character string 

NUM 

character string containing 
only numbers 

FLOAT 

floating point 

SCHAR 

single character 
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Length Parameter Table 


Values in the second column of the table above come from the 
following table of possible lengths for the template types: 


TYPE 

DESCRIPTION 

1 

No length field 

2 

One length parameter 

3 

Two parameters, the first is total digits; the sec- 
ond is the number of digits to the right of the 
decimal point. 

4 

Two parameters, the first is the number of digits to 
the left of the decimal point; the second is the 
number digits to the right of the decimal point. 

5 

Two parameters, the first is the total number of 
digits including one for the decimal point; the sec- 
ond is the number of digits to the right of the 
decimal point. I 


In cases 3, 4 and 5 above, there are several choices for the 
separator between parameters. The possibilities are: , ; . 

This information should be solicited from the user in the 
interactive session. 
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Boolean Operator Table 


Boolean 

Operation 

Your 

Operator 

Precedence 

and 



or 



not 



> 



< 



= 



>= 



< = 



1 = 



IV 



( 



) 


1 

{ 


Delimiters around lit- 


Boolean operation is columns 2—19 
Your Operator is columns 22-30 
Precedence Levels columns 38-47 
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Linguistic Convention Table 


Question 

Remark 

s 

Answer 

Spaces around operators 
required? 

Y or N 


Spaces around operators not 
required? 

Y or N 


Schematic qualified 
field name: 




Question is columns 1-40 
Remarks is columns 42-49 
Answer is columns 52-80 
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Appendix 5 - Integration of Interface Driver Software 


software t into <3iSCUSSeS h ° W t0 inte ^ rate the interface drive 


DAVID and points out routines that 
later. The sections is divided the 
on "program structure". 


may have to be modified 
same as the above section 


david.c 


navTH ai ?K Pr S g ff in * S ° nly a driver - To install it into 
david, the following changes have to be made. 


Name of the template file: 


We have been using TEST1.TMP as the default 
name. It should be changed to whatever the 
m the GSQL-ROW. 


template 
name stored 


GSQL-ROW: 

Pass GSQL-ROW to the main program instead of creating it 
using create. c * 


Name of the type conversion file: 

Change it to the correct name from TEST1.TBL. 


gettemp . c 

The naming scheme is DBMS followed by Operation Tvoe if 

£ “ 6S ? re called usi "9 other conventions 
change it accordingly. ' 


tree.c 

No change is necessary. 


create. c 

This module should be removed. 


gettable.cb 

The name changes are the same as gettemp. c. 
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buildht.c 

If more information is needed to fill the template, the 
function bu i 1 d_ha sh_t ab 1 e must be modif ied accordi^ly . T 
pack_hash function is provided to store information in 
hash table. 


typeconv.c & utility. c 

No changes are necessary. 
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Appendix 6 - IDMS code for First, Next , etc. 


How do we get the first record: 

/* READY AREA(area_name) . */ 

^?f C xSH A - CTRL - DML - SEQUENCE = SEQUENCE; 

ALL IDMS (SUBSCHEMA_CTRL, IDBMSCOM (37) 

characters */ ,AREA_NAME) ; /* a string of 16 

IF ( ERROR_STATUS <> ' 0000 ' ) THEN DO; 

STATUS_CODE = ERROR STATUS; 

GOTO END STATUS; 

END; 

/* BIND RECORD (name) . */ 

SEQUENCE = SEQUENCE + 1; 

^A?f C ^ MA - CTRL - DML - SEQUENCE = SEQUENCE; 

CALL IDMS (SUBSCHEMA_CTRL, IDBMSCOM (48) 

characters*/ ,RECORDNAME /* a string of 16 

, IN_OUT_RECORD) ; /* the actual record */ 

IF (ERROR_STATUS <> 'OOOOM THEN DO* 

STATUS_CODE = ERROR STATUS; 

GOTO END STATUS; 

END; 

"wiSSS ?S5£g? ( ? am) A8Bk( ““ -na»e >• V 

character*/ ,RECORDNAME /* a string of 16 

characters*/ /AREANAME /* a string of 16 

, IDBMSCOM (43)); 

ERROR_STATUS; RR ° R - STATUS = '° 3 ° 7/) THEN STATUS_CODE = 


How do we get the next record: 

/ SUBSCHpL N S T REC0RD(naine) ^EA (area name). */ 
SUBSCHEMA_CTRL.DML_SEQUENCE = SEOUENCE • ' ' 

CALL IDMS (SUBSCHEMA_CTRL, IDBMSCOM (11) 

, RECORDNAME /* a string of 16 
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characters */ 


, AREANAME 


characters */ 


, IDBMSCOM (43) 
IF (ERROR_STATUS = '0307') 


ERROR STATUS; 


/* a string of 16 
) r 

THEN STATUS_CODE = 


How do we close IDMS: 
/* FINISH. */ 


jc r inion • •*/ 

SUBSCHEMA CTRL. DML_SEQUENCE = SEQUENCE; 

CALL IDMS ( SUBS CHEMA_CTRL, IDBMSCOM (02)); 

IF (ERROR_STATUS <> '0000') THEN STATUS_CODE 

ERROR STATUS; 


Appendix 7 - SUBSTITUTING COMMAND NAMES 


For commands beginning with "0" 
NAME 


MEANING 


§ schema_NAME 

§file_NAME 

@area_NAME 


name of database 
name of physical 
base sits 

name of physical 


schema 

file upon which data- 
area for database 


§dbname 


database name 


@begintables 

@ tab 1 e_N AME 

@parent_NAME 

@ t ab 1 e_l eng th 

@table_position 

§table_comment 

@endtables 

§beginf ields 

@rfnam 

@rftyp 

@rf len 

@RFSIZ 

@sf ield_NAME 
@sfield_type 
@sf ield_length 


start of repeating table info 
name of table in database 
name of parent table . . . 

length of table (usually in . b Y^ e f) 
starting position of table in database 
comment about table 
end of repeating table info 
start of repeating field info 
name of field in database (formerly 
called column) 

datatype of field in database 

length of field in database 

size of field (length =) 

name of source field (used only m 
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Qsfield position 

@sf ield_comment 

@@sf ield position 

§ s f i e 1 d_coitunen t 

0RFPOS 

§RFCOM 

0endf ields 

@beginsets 

0set_NAME 

§set_owner_NAME 

@ set_member_NAME 

@endsets 


queries) 

datatype of source field (used only in 
queries) 

length of source field (used only in 
queries) 

starting position of a field 
comment about field 
starting position of a field 
comment about field 
starting position of a field 
comment about field 
end of repeating field info 
start of set info 
name of set of records 
name of owner of set 
name of member of set 
end of set info 


COMMENTS : Some 

They include: 


of the naming conventions have changed. 


confusing W ° rd Column was chan ged to field. 


Column is too 


rfield _NAME, sf ield NAME, I used simply 

generators tKis wa *' the definition 

"result" whi^hh* be ? oncerned with "source" and 

result , which have no meaning m definitions. 


In this scheme, then. 
"field_NAME" . 

field_NAME 
f ield_sname 
field rname 


the result fields will be simply 


items were added, sue] 
databases) and 

"schemas" and "areas" 


as "sets" (used in network 
(used in many big dbmss) . 
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